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PREFACE 


This manual describes the interface that a network based on the IBM X.25 SNA 
Interconnection Licensed Program (Cabbreviated as XI in this manual) provides for 
attachment of X.25 Data Terminal Equipments (DTEs). The manual is intended for 
network service providers. 


DTEs can be attached to an IBM 3725, 3720 Communication Controller running Cat least) 
the Network Control Program (NCP) and the IBM X.25 SNA Interconnection Licensed 
Program. Such an assembly of hardware (Communication Controller) and software (NCP 
and XI) is called an XI node. 


XI offers attachment through leased circuits or switched circuits. For leased 


attachment, the interface is based on the CCITT Recommendation X.25. For switched 
attachment, the interface is based on the CCITT Recommendation X.32. 


iv XI DTE/DCE Interface Description 


IBM Confidential 


Overview of XI functions 


oth switched virtual circuits (SVCs) and permanent virtual circuits (PVCs) are 
available with XI. 


DTEs based on the 1984 or 1980 version of the Recommendation can be attached to an 
XI node and can communicate through SVCs or PVCs with DTEs based on either version 
1980 or version 1984 of X.25. <A summary of the differences between X.25 CCITT 1984 
and 1980 is given in Annex H. 


DTES can communicate with DTEs attached to the same XI node, or to another XI node. 

They can also communicate with DTEs attached to a Packet Switched Data Network (PSDN) 
complying with Recommendation X.25, through the Gateway function of XI (referred to 

as GW-DTE, as it presents a DTE function to the PSDN). 


DTEs can be attached to XI nodes either by leased lines or by switched lines. This 
manual specifies only the interface for the DTEs attached to an XI node. However, 

addressing conventions for communicating with DTEs attached to PSDNs are described 

in 5.8. 


The XI Licensed Program requires the Network Supervisory Function Licensed Program 
(NSF) as a prerequisite program in an SNA host for management purposes. 


Terms and conventions 


In this manual, some CCITT terms are used that need further explanation, and some 
CCITT conventions are used that differ from normal IBM terms and conventions: 


e For "virtual call” understand "switched virtual circuit”. 
e For “network” understand a collection of communicating XI nodes inside a single 
addressing scheme (XI network). 
©} For “Administration” understand "network service provider". 
° For "subscription”™ understand the procedure defined by the network service 


provider to install DTE access links and set the DTE/DCE subscription parameters 
to consistent values. 


° For "international™ understand any networks that may be reached outside of the 
addressing scheme of the XI network, such as PSDNs connected through the 
gateway-DTE function or through transit PSDNs. 

e For "octet" read "byte". 


e The CCITT numbering of bits is used for the description of frames and packets. 
This numbering is different from the one normally used in IBM documentation. 


IBM Confidential 


Related Publications 


The other publications for XI and NSF are: 


vi 


XI_ ViIR1I Licensed Program Specification, GH19-6573 
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XI_and NSF Planning and Installation, GH19-6577 
XI_ and NSF Operation, SH19-6578 

XI_and NSF Diagnosis Guide, LY19-6281 
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Correspondence with CCITT Recommendation X.25 


The DTE interface provided by XI is based on the 1984 version of CCITT Recommendation 
X.25, but maintains compatibility with the 1980 version. 


Notes: 


In this part, portions of CCITT Recommendation X.25 (Malaga-Torremolinos, October 
1984) from the CCITT VIIIth Plenary Assembly Red Book, Volume III - Fascicle III.3 
are reproduced with special authorization of the International Telecommunications 
Union CITU). 


The ‘CCITT paragraph numbering has been used to facilitate comparison with the 
CCITT Recommendation, which is the authorative source. IBM has made every effort 
to accurately reproduce the CCITT Recommendation X.25. However errors may have 
been introduced inadvertently. To ensure complete accuracy, the customer should 
obtain the Recommendation directly from CCITT. 


XI-specific text is indicated by a vertical line in the left margin. 


Sections of the CCITT text not applicable to XI (such as additional facilities 
not implemented), are either omitted or marked "not applicable to XI". 


Paragraphs and sentences related to features not supported by XI have been 
omitted. : 


A major difference from Recommendation X.25 is that the XI specifications exclude 


the physical attachment of DTEs to the XI nodes. The XI specifications apply to the 


junction with the Communication Controller physical port as shown in the following 
figure: 


physical link 


X.25 XI 
Recommendation specifications 
reference point reference point 


Note: This example shows an access link with an analog transmission line anda pair 


of modems (M). The access link can also be a leased digital circuit with an X.21 
interface. 


XI specifications include some guidance on the monitoring of the physical link between 
the DTE and the DCE. 
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RECOMMENDATION X.25 


© INTERFACE BETWEEN DATA TERMINAL EQUIPMENT CDTE) AND DATA 
CIRCUIT TERMINATING EQUIPMENT (DCE) FOR TERMINALS OPERATING 
IN THE PACKET MODE AND CONNECTED TO PUBLIC 
DATA NETWORKS BY DEDICATED CIRCUIT 


(Geneva, 1976, amended at Geneva, 1980 
and Malaga-Torremolinos, 1984) 


The establishment In various countries of public data networks providing 
packet-switched data transmission services creates a need to produce standards to 
facilitate international interworking. 


The CCITT, considering: 


Ca) That Recommendation X.1 includes specific user classes of service for data 
terminal equipments operating in the packet mode, Recommendation X.2 defines user 
facilities, Recommendation X.10 defines categories of access, Recommendations X.21 
and X.21 bis define DTE/DCE physical level interface characteristics, Recommendation 
X.92 defines the hypothetical reference connections for packet-switched data 
transmission service and Recommendation X.96 defines call progress signals; 


(b) That data terminal equipments operating in the packet mode will send and receive 
network control information in the form of packets; 


(c) That certain data terminal equipments operating in the packet mode will use a 
packet interleaved synchronous data circuit; 


Cd) The desirability of being able to use a single data circuit to a Data Switching 
ee (DSE) for all user facilities; 


e) That Recommendation X.2 designates virtual call and permanent virtual circuit 
services as essential (CE) services to be provided by all networks; 


Cf) The need for defining an international Recommendation for the exchange between 
DTE and DCE of control information for the use of packet-switched data transmission 
services; 


(g) That this definition is made in Recommendation X.32 with regard to the access 
through a public switched telephone network or a circuit switched public data network; 


Ch) That, when this Recommendation is used to provide the Network service defined in 
Recommendation X.213, the physical, link and packet levels correspond to the Physical, 
Data link and Network layers respectively, as defined in Recommendation X.200; 


C1) That this Recommendation includes features which are not necessary to provide the 
services included in Recommendation X.213;3 


(j) That the necessary elements for an interface Recommendation should be defined 
independently as: 


Physical level - the mechanical, electrical, functional and procedural 
characteristics to activate, maintain and deactivate the physical link between the 
DTE and the DCE; 


Link level - the link access procedure for data interchange across the link between 
the DTE and the DCE; 


Packet level - the the packet formats and control procedures for the exchange of 
packets containing control information and user data between the DTE and the DCE; 
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Unanimously declares the view that for data terminal equipments operating in the 
packet mode: 


(1) The mechanical, electrical, functional and procedural characteristics to 
activate, maintain and deactivate the physical link between the DTE and the DCE should 
be as specified in 1 below, DTE/DCE interface characteristics; 


€2) The link access procedure for data interchange across the link between the DTE 


and the DCE should be as specified in 2 below, Link access procedure across the DTE/DCE 
interface; 


C3) The packet level procedures for the exchange of control information and user data 


at the DTE/DCE interface should be as specified tn 3 below, Description of the packet 
level DTE/DCE interface; 


€4) The procedures for virtual call and permanent virtual circuit services should be 
as specified in 4 below, Procedures for virtual circuit services; 


(5) The format for packets exchanged between the DTE and the DCE should be as specified 
in 5 below, Packet formats; 


(6) The procedures for optional user facilities should be as specified in 6 below, 
Procedures for optional user facilities; 


(7) The formats for optional user facilities should be as specified in 7 below, 
Formats for facility fields and registration fields. 
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1. DTE/DCE INTERFACE CHARACTERISTICS (PHYSICAL LEVEL) 


| XI nodes offer physical interfaces compatible with V.24, V.35, and X.21 leased 
| tandards. The specifications of these interfaces are available in the documentation 


or the physical interfaces of the communication controllers supporting the XI node 
unction. The line access speed can be between 2400 and 64000 bps. 


The physical interface is activated/deactivated through network operator commands. 
With XI, it is not possible to establish test loops through network operator commands. 
Test loops can be manually activated Cif the modem or the X.21 adaptor has the 
appropriate feature), but this may issue a deactivation of the physical interface if 
the test duration exceeds a value of 5 seconds. 


In the same way, if a failure occurs on the DTE/DCE junction, which sets the physical 
interface to an abnormal status, transmission from the XI node can be delayed up to 
the same 5 seconds value before the interface is declared to be in error. If this 
value is exceeded, recovery procedures need to be initiated from the network operator, 
and if the failure cannot be repaired (e.g. access line out of order), the interface 
1s then deactivated. 


As indicated in the Preface, the following sections which describe the physical level 
of the DTE/DCE interface are not applicable to XI specifications. The XI reference 

point is the physical junction with the Communication Controller physical port, not 

the physical junction with the X.25 DTE. However, some indications are given when the 
physical attachment is with IBM modems (see Section 1.3, V-Series Interface 


Administrations may offer one or more of the interfaces specified below. 


1.1 X.21 INTERFACE 


The X.21 Interface is supported without qualification. 


o* X.21 BIS INTERFACE 


The X.21 Bis Interface is Supported without qualification. 


1.3 V-SERIES INTERFACE 


V-Series Interface are supported with the following qualification. 

With IBM modems of the 586x family (5865 model 2 and 3, 5866 model 2 and 3, 5868 model 
52 and 62), XI allows the network operator to run modem and line tests. Occurrences 
of such tests cause the modem adjacent to the DTE to set CCITT V.24 circuit 142 to 
the ON condition for the duration of the test. 


During the test duration, the modem can neither transmit nor receive. 
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2. LINK ACCESS PROCEDURE ACROSS THE DTE/DCE INTERFACE 


2.1 SCOPE AND FIELD OF APPLICATIONS 


2.1.1 


The Link Access Procedures (LAPB and LAP) are described as the Link Level Element and 
are used for data interchange between a DCE and DTE over a single physical circuit 
CLAPB and LAP), or optionally over multiple physical circuits (CLAPB), operating in 
user classes of service 8 to 11 as indicated in Recommendation X.1. 


The single link procedures (SLPs) described in 2.2, 2.3, and 2.4% CLAPB) and in 2.2, 
2.6, and 2.7 CLAP) are used for data interchange over a single physical circuit, 
conforming to the description given in 1, between a DTE and a DCE. 


2.1.2 


The single Link procedures (SLPs) use the principles and terminology of the High-level 
Data Link Control CHDLC) procedures specified by the International Organization for 
Standardization CISQO). 


2.1.3 


Each transmission facility is duplex. 


2.1.4 @ 


DCE compatibility of operation with the ISO balanced classes of procedure (Class BA 
with options 2, 8, and Class BA with options 2, 8, 10) is achieved using the LAPB 
procedure described in 2.3, and 2.4 in this Recommendation. Of these classes, Class 
BA with options 2, 8 CLAPB modulo 8) is the basic service, and is available in all 
networks. 


2.1.5 


XI supports only the basic mode (modulo 8). SABME command cannot be used by the DTE. 


2.1.6 


XI offers only the LAPB procedure. 
2.c¢ FRAME STRUCTURE 


2.e-l1 Introduction 


All transmissions on a SLP are in frames conforming to one of the formats of Table 
1/X.25 for basic (modulo 8) operation, or alternatively one of the formats of Table 
2/X.25 for extended (modulo 128) operation. The flag preceding the address field is @ 
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defined as the opening flag. The flag following the FCS field is defined as the 
closing flag. 


Flag Sequence 


All frames shall start and end with the flag sequence consisting of one 0 bit following 
by S1x contiguous 1 bits and one 0 bit. The DTE and DCE shall only send complete 
eight-bit flag sequences when sending multiple flag sequence (see 2.2.11). A single 


flag may be used as both the closing flag for one frame and the opening flag for the 
next frame. 


TABLE 1/7X.25 


Bit order of transmission: 


12345678 12345678 12345678 16 to 1 12345678 


rise [sete [entonn [res 
01111110 16-bits |01111110 


FCS Frame Check Sequence 


@ Bit order of transmission: 
12345678 12345678 12345678 16 to 1 12345678 


cs fs |e | mo [rs | 


FCS Frame Check Sequence 


Table 2/X.25( Frame formats - Extended (modulo 128) operation) is not applicable in 
the XI environment. 


2.2.3 Address Field 


The address field shall consist of one octet. The address field identifies the 
intended receiver of a command frame and the transmitter of a response frame. The 
coding of the address field is described in 2.4.2 CLAPB) and in 2.7.1 CLAP) below. 


2.2.% Control Field 


For modulo 8 (basic) operation the control field shall consist of one octet. The 
content of this field is described in 2.3.2 CLAPB) and in 2.6.2 CLAP) below. 
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2.2.5 Information Field 


The information field of a frame, when present, follows the control field (see 2.2.4 
above) and precedes the frame check sequence (see 2.2.7 below). 


See 2.3.4.9, 2.5.2, 2.6.4.8, and 5 for the various coding and groupings of bits in 
the information field as used in this Recommendation. 


See 2.3.4.9, 2.4.8.5, 2.6.4.8, and 2.7.7.5 below with regard to the maximum 
information field length. 


2.2.6 Transparency 


The DCE, when transmitting, shall examine the frame content between the two flag 
sequences tncluding the address, control, information and FCS field and shall insert 
a 0 bit after all sequence of 5 contiguous 1 bits Cincluding the last 5 bits of the 
FCS) to ensure that a flag sequence is not simulated. The DCE or DTE, when receiving, 
shall examine the frame content and shall discard any 0 bit which directly follows 5 
contiguous 1 bits. 


2.2.7 Frame Check Sequence (FCS) Field 


The notation used to describe the FCS is based on the property of cyclic codes that 
a code vector such as 1000000100001 can be represented by a polynomial P(x) = xi? + 
x> + 1. The elements of an n-element code word are thus the coefficients of a 
polynomial of order n-1l. In this application, these coefficients can have the value 
0 or 1 and the polynomial operations are performed modulo 2. The polynomial 
representing the content of a frame is generated using the first bit received after 
the frame opening flag the coefficient of the highest order term. 


The FCS field shall be a 16-bit sequence. It shall be the ones complement of the 
sum (modulo 2) of: 


1. The remainder of xk Cx? + 92S F yl + yt? £ yw tb + yO 4 KF £ yF + x7? + yO 
+ x5 + x4 + x + x? + x? + :1) divided (modulo 2) by the generator polynomial 
x26 + yl2 + x5 + 1, where k is the number of bits in the frame existing between, 
but not including, the final bit of the opening flag and the first bit 
of the FCS, excluding bits inserted for transparency, and 


2. The remainder of the division (modulo 2) by the generator polynomial x!® + x}2 
+ x°® + 1 of the product of x!® by the content of the frame, existing between 
but not including, the final bit of the opening flag and the first bit of the 
FCS excluding bits inserted for transparency. 


Note - Within the first sentence, the term "xk" should be read as "x to the power of 
Kk. 


As a typical implementation, at the transmitter, the tnitial content of the register 
containing the remainder of the division is preset to all 1s and is then modified by 
division by the generator polynomial (Cas described above) on the address, control and 


information field; the ones complement of the resulting remainder is transmitted as 
the 16-bits FCS. 


At the receiver, the initial content of the register of the devices computing the 
remainder is preset to all ls. The final remainder, after multiplication by x!?® and 
then division (modulo 2) by the generator polynomial x?® + x!2 + x5 + 1 of the serial 
incoming protected bits and the FCS, will be 0001110100001111 € x?5 through x?®, 
respectively) in the absence of transmission errors. 


Note - Examples of transmitted bit patterns by the DCE and the DTE illustrating 


application of the transparency mechanism and the frame check sequence to the SABM 
command and the UA response are given in Appendix I. 
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2.2.8 Order of Bit Transmission 


Eee GED 


Addresses, commands, responses and sequence numbers shall be transmitted with the low 
order bit first (for example, the first bit of the sequence number that is transmitted 
hall have the weight 2°. The order of transmitting bits within the information field 

@: not specified under 2 of this highest term, which is found in bit position 16 of 
he FCS field (see Tables 1/X.25 and 2/X.25). 


Note - In Tables 17X.25 to 13/X.25, the low-order bit is defined as bit 1. 


2.2.9 Invalid Frames 


a definition of an invalid frame is described in 2.3.5.3 (CLAPB) and in 2.6.5.3 (LAP) 
elow. 


2.2.10 Frame Abortion 


Aborting a frame is performed by transmitting at least seven contiguous 1 bits (with 
no inserted 0 bits). 


| XI does not perform frame abortion: A frame received by the DTE containing at least 
| 7 consecutive bits set to 1 can only result from transmission errors. 


2.e.ll Interface time fill 


Interface time fill is accomplished by transmitting contiguous flags between frames, 
i1.e., multiple eight-bit flag sequence (see 2.2.2). 


@.2.12 Link channel states 


A link channel as defined here is the means for transmission for one direction. 


2.2e.12.1 active channel state 


The DCE incoming or outgoing channel is defined to be in an active condition when it 
is receiving or transmitting, respectively, a frame, an abortion sequence or 
interframe time fill. 


2.2.12.2 Idle channel state 


The DCE incoming or outgoing channel is defined to be in an idle condition when it 


is receiving or transmitting, respectively, a continuous 1 state for a period of at 
least 15 bit times. 


See 2.3.5.5 for a description of DCE action when an idle condition exists on its 
incoming channel for an excessive period of time. 
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2.3 LAPB ELEMENTS OF PROCEDURES 


SRG ER EE ED 


2.3.1 Introduction 


The LAPB elements of procedures specified below contain the selection of commands and 
responses relevant to the LAPB link and system configurations described in 2.1 above. 


Together, 2.2 and 2.3 form the general requirements for the proper management of a 
LAPB access link. 


2.3.2 LAPB control field formats and parameters 


2.3.-e.l1 Control field formats 


The control field contains a command or a response, and sequence numbers where 
applicable. 


Three types of control field formats are used to perform numbered information transfer 
(I format). Numbered supervisory functions (s format) and unnumbered control 
functions Cu format). : 
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The control field formats for basic (modulo 8) operation are depicted in TABLE 3/X.25. 


TABLE 3/X.25 


_ LAPB control field formats - Basic (modulo 8) operation 


Control Field Bits] 1 2 3 4 5 6 7 8 
[ifort po] use [am 


NCS) Transmitter send sequence number (bit 2 = low-order bit) 

NCR) Transmitter receive sequence number (bit 6 = low-order bit) 

S Supervisory function bit 

M Modifier function bit 

P/F Poll bit when issued as a command, final bit when issued as 
a response (1 = Poll/Final) 

P Poll bit (1 = Poll) 


| Table 4/X.25 (CLAPB control field formats - Extended (modulo 128) operation) is not 
| applicable in the XI environment. 


2.3.2.1.1 Information transfer format - I 


The I format is used to perform an information transfer. The functions of NCS), NCR) 
and P are independent; i.e.» each I frame has an NCS) and NCR) which may or may not 
acknowledge additional I frames received by the DCE or DTE anda P bit that may be 


set to 0 or il. 
@ °° Supervisory format - 5S 


The S format is used to perform data link supervisory control functions such as 
acknowledge I frames, request retransmission of I frames, and to request a temporary 
suspension of transmission of I frames. The functions of NCR) and P/F are 
independent; i.e., each supervisory frame has an NCR) which may or may not acknowledge 
additional I frames received by the DCE or DTE, and a P/F bit that may be set to 0 
or l. 


2.3.2.1.3 Unnumbered format - U 


The U format is used to provide additional data link control functions. This format 
contains no sequence numbers, but does include a P/F bit that may be set to 0 or 1. 
The unnumbered frames have the same control field length Cone octet) is both basic 
(modulo 8) operation and extended (modulo 128) operation. 


2.3-c.e2 Control field parameters 


The various parameters associated with the control field are described below. 


2.3.2.2.1 Modulus 


Each I frame is sequentially numbered and may have the value 0 through modulus minus 
| 1 (where "modulus”™ is the modulus of the sequence numbers). The modulus equals 8 and 
|} the sequence cycle through the entire range. 
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2.3.2.2.2 Send state variable V(S) 


The send state variable V(S) denotes the sequence number of the next tn-sequence I 
frame to be transmitted. VCS) can take on the value 0 through modulus minus 1. The 
value of VCS) is incremented by I with each successive [I frame transmission, but 
cannot exceed NCR) of the last received I or supervisory frame by more than the maximum 
number of outstanding I frames (k). The value of k is defined in 2.4.8.6. below. 


2.3.2.2.3 Send sequence number NCS) 


Only I frames contain NCS), the send sequence number of transmitted I frames. At the 
time that an in-sequence I frame is designated for transmission, the value of N(S) 
is set equal to the value of the send state variable V(S). 


2.3.2.2.-% Receive state variable VCR) 


The receive state variable VCR) denotes the sequence number of the next in-sequence 
I frame expected to be received. VCR) can take on the value 0 through modulus minus 
1. The value of VCR) is incremented by 1 by the receipt of an error-free, in-sequence 
I frame whose send sequence number N(S) equals the receive state variable VCR). . 


2.3.2.2.5 Receive sequence number N(R) 


All I frames and supervisory frames contain NCR), the expected send sequence number 
of the next received I frame. At the time that a frame of the above types is 
designated for transmission, the value of NCR) is set equal to the current value of 
the receive state variable VCR). NCR) indicates that the DCE or DTE transmitting the 
NCR) has received correctly all I frames numbered up to and including NCR)-1. 


2.3.2.2.6 Poll/Final Bit P/F 


All frames contain P/F, the Poll/Final bit. In command frames the P/F bit is referred 
to as the P bit. In response frames it is referred to as the F bit. 


2.3.3 Functions of the Poll/Final Bit 


The Poll bit set to 1 is used by the DCE or DTE to solicit Cpoll) a response from the 
DTE or DCE, respectively. The Final bit set to 1 1s used by the DCE or DTE to indicate 
the response frame transmitted by the DTE or DCE, respectively», as a result of the 
soliciting Cpoll) command. 


The use of the P/F bit 1s described in 2.4.3 below. 
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2.3.4 Commands and Responses 


For basic (modulo 8) operation, the commands and response represented in Table 5/X.25 


will be supported by the DCE and the DTE. 


TABLE 5/7X.25 


LAPB Commands and Responses - Basic (Modulo 8) Operation 


nformation 
transfer I Cinformation) 


I 

Supervisory|RR Creceive RR Creceive 
ready) ready) 

RNR Creceive RNR Creceive 
not ready) not ready) 

REJ Creject) REJ Creject) 


Unnumbered |[SABM Cset 
asynchronous 
balanced mode) 
DISC(disconnect)}| == ss 1 10 0 es 0 1 0 
DM (€discon- 
nected mode) 11 %i1é#é%Mti1 F 


UA Cunnumbe- 
red acknowl- 
F 


edgment) 


Table 6/X.25 CLAPB commands and response - Extended (modulo 128) operation) is not 


applicable in the XI environment. 


For purposes of the LAPB procedures, the supervisory function bit encoding "11" and 


those encoding of modifier function bits in Tables 5/X.25 or 6/X.25 are identified 


as "undefined or not implemented” command and response control field. 


The commands and responses in Table 5/X.25 are defined as follows: 


2.3.4.1 Information (I) Command 


The function of the information (I) command is to transfer across a data link a 
sequentially numbered frame containing an information field. 


2.3.4.2 Receive Ready (RR) Command and Response 


The receive ready CRR) supervisory frame is used by the DCE or DTE to: 
1. Indicate it is ready to receive an I frame 


2. Acknowledge previously received I frames numbered up to including NCR)-1. 
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An RR frame may be used to indicate the clearance of a busy condition that was reported 
by the earlier transmission of an RNR frame by that same station (DCE or DTE). In 

addition to indicating the DCE or DTE status, the RR command with the P bit set to l 
may be used by the DCE or DTE to ask for the status of the DTE or DCE, respectively. 


In the absence of traffic on the line, the XI DCE starts optionally an inactivity timer 
Ti. Ti time-out causes the XI DCE to send an RR command, with P bit set to 1. In the 
absence of an RR response from the DTE, the XI DCE retransmits the RR command, up to 
N2 times. When the threshold of N2 retries is reached, the XI DCE enters in the 
disconnected phase. 


2.3.4.3 Receive Not Ready (RNR) Command and Response 


The receive not ready (RNR) supervisory frame is used by the DCE or DTE to indicate 
a busy condition, i.e., temporary inability to accept additional incoming I frames. 
I frames numbered up to and including NCR) - 1 are acknowledged. I frame NCR) and 
any subsequent I frames received, if any,» are not acknowledged; the acceptance status 
of these I frames will be indicated in subsequent exchanges. 


In addition to indicating the DCE or DTE status, the RNR command with the P bit set 
to 1 may be used by the DCE or DTE to ask for the status of the DTE or DCE, 
respectively. 


2.3.4.4 Reject (REJ) Command and Response 


The reject CREJ) supervisory frame is used by the DCE or DTE to request transmission 
of I frames starting with the frame numbered NCR). I frames numbered NCR) - 1 and 
below are acknowledged. Additional I frames pending initial transmission may be 
transmitted following the retransmitted I frame(s). 


Only one REJ exception condition of information transfer may be established at any 
time. The REJ exception condition is cleared Creset) upon the receipt of an I frame 
with an NCS) equal to NCR) of the REJ frame. 


An REJ frame may be used to indicate the clearance of a busy condition that was 
reported by the earlier transmission of an RNR frame by that same station (DCE or DTE). 
In addition to indicating the DCE or DTE status, the REJ command with the P bit set 
to 1 may be used by the DCE or DTE to ask for the status of the DTE or DCE, 
respectively. 


XI does not send REJ commands. REJ commands received from a DTE are handled as 
required by the procedure described here. 


2.3.4.5 Set Asynchronous Balanced Mode (SABM) Command 


The SABM unnumbered command is used to place the addressed DCE or DTE in an 
asynchronous balanced mode CABM) information transfer phase where all 
command/response control fields will be one octet in length. 


The SABME unnumbered command 1s not applicable in the XI environment. 


No information field is permitted with the SABM command. The transmission of SABM 
command indicates the clearance of a busy condition that was reported by the earlier 
transmission of an RNR frame by that same station (CDCE or DTE). The DCE or DTE 
confirms acceptance of SABM (modulo 8 (basic) operation) command by the transmission 
at the first opportunity of a UA response. Upon acceptance of this command, the DCE 


or DTE send state variable VCS) and receive state variable VCR) are set to 0. 


Previously transmitted I frames that are unacknowledged when this command is actioned 
remain unacknowledged. It is the responsibility of a higher level Ce.g., packet level 
or MLP) to recover from the possible loss of the contents of such I frames. 

Modulo 128 is not applicable in the XI environment. 


XI never sends SABM frames. 
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2.3-4.6 Disconnect (DISC) Command 


The DISC unnumbered command is used to terminate the mode previously set. It is used 
to inform the DCE or DTE receiving the DISC command that the DTE or DCE sending the 


@ oon command 1s suspending operation. No information field is permitted with the DISC 


ommand. Prior to actioning the DISC command, the DCE or DTE receiving the DISC 
command confirms the acceptance of the DISC command by the transmission of a UA 
response. The DTE or DCE sending the DISC command enters the disconnected phase when 
it receives the acknowledging UA response. 


Previously transmitted I frames that are unacknowledged when this command is actioned 
remain unacknowledged. It is the responsibility of a higher level (e.g., Packet Level 
or MLP) to recover from the possible loss of the contents of such I frames. 


The only case where XI sends a DISC frame is when a command is received from the 


network operator deactivating the DTE/DCE interface. The DISC frame is then sent with 
P bit set to l. 


2.3.4.7 Unnumbered Acknowledgment (UA) Response 


The UA unnumbered response is used by the DCE or DTE to acknowledge the receipt and 
acceptance of the mode-setting commands. Received mode-setting commands are not 
actioned until the UA response is transmitted. The transmission of a UA response 
indicates the clearance of a busy condition that was reported by the earlier 
transmission of an RNR frame by that same station (DCE or DTE). No information field 
is permitted with the UA response. 


2.3.4.8 Disconnected Mode (DM) Response 


The DM unnumbered response is used to report a status where the DCE or DTE 1s logically 
disconnected from the link, and 1s in the disconnected phase. The DM response may 
be sent to indicate that the DCE or DTE has entered the disconnected phase without 
enefit of having received a DISC command, or, if sent in response to the reception 
f a mode setting command, is sent to inform the DTE or DCE that the DCE or DTE, 
respectively, is still in the disconnected phase and cannot action the set mode 
command. No information field is permitted with the DM response. 


A DCE or DTE in a disconnected phase will monitor received commands and will react 


to an SABM command as outlined in 2.4.4 below, and will respond with the F bit set 
to 1 to any other command received with the P bit set to 1. 


2.3.%.9 Frame Reject (FRMR) Response 


The FRMR unnumbered response is used by the DCE or DTE to report an error condition 
not recoverable by retransmitting of the identical frame: 1.e., at least one of the 
following conditions, which results from the receipt of a valid frame: 


1. The receipt of a command or response control field that is undefined or not 
implemented; 


2. The receipt of an I frame with an information field which exceeds the maximum 
established length, 


3. The receipt of an tnvalid NCR), or 


4. The receipt of a frame with an information field which ts not permitted or the 
receipt of a supervisory or unnumbered frame with incorrect length. 


An undefined or not implemented control field is any of the control field encoding 
that are not identified tin Tables 5/X.25 or 6/X.25. 


A valid NCR) must be within the range from the lowest send sequence number NCS) of 
the still unacknowledged frame(s) to the current DCE send state variable included (or 
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to the current internal variable x if the DCE is in the timer recovery condition as 
described in 2.4.5.9). 


An information field which immediately follows the control field, and consists of 3 
or five octets (modulo 8 (basic) operation or modulo 128 Cextended) operation, 


respectively), is returned with this response and provides the reason for the FRMR } 
response. These formats are given tn Tables 7/X.25 and 8/X.25. 
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TABLE 77X.25 
LAPB FRMR Information Field Format - Basic (Modulo 8) Operation 
@ Information field bits 
12345678 9 101112 13 14 15 16 17 18 19 20 21 22 23 24 


Rejected frame 
control field VCS) C/R VOR) X TY {2 


Rejected frame control field is the control field of the received frame which caused 
the frame reject. 


V(S) is the current send state variable value at the DCE or DTE reporting the 
reyection condition CBit 10 = low-order bit). 

C/R set to 1 indicates the rejected frame was a response. C/R set to 0 indicates 
the rejected frame was a command. 

VCR) 15 the current receive state variable value at the DCE or DTE reporting the 
rejection condition (Bit 14 = low-order bit). 

W set to 1 indicates that the control field received and returned in bits 1 


through 8 was undefined or not implemented. 


X set to 1 indicates that the control field received and returned in bits 1 
through 8 was considered invalid because the frame contained an information 
field which is not permitted with this frame or is a supervisory of 
unnumbered frame with incorrect length. Bit W must be set to l in 
conjunction with this bit. 


Y set to 1 indicates that the information field received exceeded the maxtmum 
established capacity. 


r set to 1 indicates the control field received and returned in bits 1 through 
8 contained an invalid NCR). 


Bits 9 and 21 to 24 shall be set to 0. 


| Table 8/X.25 CLAPB FRMR information field format - Extended (modulo 128) operation) 
[ is not applicable in the XI environment. 


2.3.5 Exception Condition Reporting and Recover 


The error recovery procedures which are available to effect recovery following the 
detection/occurrence of an exception condition at the Data Link Level are described 
below. Exception conditions described are those situations which may occur as the 
result of transmission errors, DCE or DTE malfunction, or operational situations. 


2.3.5.1 Busy Condition 


The busy condition results when the DCE or DTE is temporarily unable to continue to 
receive I frames due to internal constraints, e.g., receive buffering Limitations. 
In this case an RNR frame is transmitted from the busy DCE or DTE. I frames pending 
transmission may be transmitted from the busy DCE or DTE prior to or following the 
RNR frame. 


| An indication that the busy condition has cleared is communicated by the transmission 
| of a UA Conly in response to a SABM command), RR, REJ, or SABM (modulo 8) frame. 
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The XI DCE takes into account the clearing of a busy condition of the DTE by any of 
the methods described above. The XI DCE clears a busy condition by sending an RR 
frame. 


The XI DCE enters in a busy condition when a modem or line test is run. It clears its 
busy condition at the completion of the test. r ) 


2.3.5.2 N(S) Sequence Error Condition 


The information field of all I frames received whose N(S) does not equal the receive 


state variable VCR) will be discarded. 


An NCS) sequence error exception condition occurs tn the receiver when an I frame 
received contains an NCS) which is not equal to the receive state variable VCR) at 
the receiver. The receiver does not acknowledge Cincrement its receive state 
variable) the I frame causing the sequence error, or any I frame which may follow, 
until an I frame with the correct N(S) is received. | 


A DCE or DTE which receives one or more valid I frames having sequence errors or 
subsequent S format frames CRR, RNR, and REJ) shall accept the control information 
contained in the NCR) field and the P bit to perform link control functions; e.g.» 
to receive acknowledgment of previously transmitted I frames and to cause the DCE or 
DTE to respond (P bit set to 1). 


The means specified in 2.3.5.2.1 and 2.3.5.2.2 shall be available for initiating the 
retransmission of lost or errored I frames following the occurrence of a NCS) sequence 
error condition. 


2.3.5.2.1 REJ Recovery 


The REJ frame is used by a receiving DCE or DTE to initiate a recovery Cretransmitting) 
following the detection of an NCS) sequence error. 


With respect to each direction of transmission on the data link, only one "sent REJ" 
exception condition from a DCE or DTE, to a DTE or DCE, is established at a time. A 
"sent REJ"™ exception condition is cleared when the requested I frame is received. © 


A DCE or DTE receiving a REJ frame initiates sequential (Cre-)transmission of I frames 
starting with the I frame indicated by the NCR) contained in the REJ frame. The 
retransmitted frames may contain an NCR) and a P bit that are updated from, and 
therefore different from, the ones contained in the originally transmitted I frames. 


2.3.5.2.2 Time-out Recovery 


If a DCE or DTE, due to a transmission error, does not receive Cor receives and 
discards) a single I frame or the last I frame(s) in a sequence of I frames, it will 
not detect a NCS) sequence error condition and, therefore, will not transmit a REJ 
frame. The DTE or DCE which transmitted the unacknowledged I frame(€s) shall, 
following the completion of a system specified time-out period Csee 2.4.5.1 and 
2.4.5.9 below), take appropriate recovery action to determine at which I frame 
retransmitting must begin. The retransmitted frame(s) may contain an NCR) and a P 
bit that 1s updated from, and therefore different from, the ones contained in the 
originally transmitted I frame(s). - 


2.3.5.3 Invalid Frame Condition 

Any frame which is invalid will be discarded, and no action is taken as the result 
of that frame. An invalid frame is defined as one which: 

1. Is not properly bounded by two flags, 

2. In basic (modulo 8) operation, contains fewer than 32 bits between flags, 

3. Contains a Frame Check Sequence (FCS) error, 


4. Contains an address other than A or B (for single link operation) or other than @ 
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C or D Cfor multilink operation). 


For those networks that are octet aligned, a detection of non-octet alignment may be 
made at the Data Link Level by adding a frame validity check that requires the number 


of bits between the opening flag and the closing flag, excluding bits inserted for 
eo... to be an integral number of octets in length, or the frame is considered 
nvalid. 


| XI networks are octet aligned. 


2.3.5.4 Frame Rejection Condition 


A frame rejection condition is established upon the receipt of an error-free frame 
with one of the conditions listed in 2.3.4.9 above. 


At the DCE or DTE, this frame rejection exception condition is reported by a FRMR 


response for appropriate DTE or DCE action, respectively. Once a DCE has established 
such an exception condition, no additional I frames are accepted until the condition 


is reset by the DTE, except for examination of the P bit. The FRMR response may be 
repeated at each opportunity, as specified in 2.4.7.3, until recovery is effected by 
the DTE, or until the DCE initiates its own recovery. | 


2.3.5.5 Excessive Idle Channel State Condition on Incoming Channel 


Upon detection of an idle channel state condition (see 2.2.12.2) on the incoming 
channel, the DCE shall wait for a period T3 (see 2.4.8.3) without taking any specific 
action, waiting for detection of a return to the active channel state (that is, 


detection of at least one flag sequence). After the period T3, the DCE shall notify 


the Packet Level of the excessive idle channel state condition, but shall not take 


any action that would preclude the DTE from establishing the data link by normal link 


set-up procedures. 


| XI does not detect an idle condition on the transmission channel from the DTE, and 
oes not take any action whatsoever for the duration of this idle condition. 


i - Other actions to be taken by the DCE at the Data Link Level upon expiration 
of period T3 is a subject for further study. 


2.4 DESCRIPTION OF THE LAPB PROCEDURE 


2.4.1 LAPB Basic and Extended Modes of Operation 


In accordance with the system choice made by the DTE at subscription time, the DCE 
either will support modulo 8 (basic) operation or modulo 128 Cextended) operation. 


| Modulo 128 is not applicable in the XI environment. 
Table 5/X.25 indicates the command and response control field formats used with the 
basic (modulo 8) service. The mode setting command employed to initialize (set up) 
or reset the basic mode is the SABM command. 


| Table 6/X.25 is not applicable in the XI environment. 


2.4.2 LAPB Procedure for Addressin 


The address field identifies a frame as either a command or a response. A command 
frame contains the address of the DCE or DTE to which the command is being sent. A 
response frame contains the address of the DCE or DTE sending the frame. 
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Multilink operation is not applicable in the XI environment. 


Frames containing command transferred from the DCE to the DTE will contain the address 
A for the single operation and address C for the multilink operation. 


Frames containing response transferred from the DCE to the DTE will contain the 
address B for the single link operation and address D for the multilink operation. 


Frames containing command transferred from the DTE to the DCE shall contain the 
address B for the single link operation and address D for the multilink operation. 


Frames containing response transferred from the DTE to the DCE shall contain the 
address A for the single link operation and address C for the multilink operation. 


These address are coded as follows: 


Address 1234567 8 
Single link operation A 11000000 
B 1000000 0 


Multilink operation 1s not applicable in the XI environment. 


Note - The DCE will discard all frames received with an address other than A or B 
Csingle link operation), or C or D Cmultilink operation). 


2.4.3 LAPB Procedure for the Use of the P/F Bit 


The DCE or DTE receiving an SABM, DISC, supervisory command, or I frame with the P 
bit set to 1 will set the F bit to 1 in the next response frame it transmits. 


The response frame returned by the DCE to an SABM or DISC command with the P bit set 
to 1 will be a UA or DM response with the F bit set to 1. The response frame returned 
by the DCE to an I frame with the P bit set to 1, received during the information 
transfer phase, will be an RR, REJ, RNR or FRMR response with the F bit set to 1. 
The response frame returned by the DCE to a supervisory command with the P bit set 
to 1, received during the information transfer phase, will be an RR, REJ, RNR or FRMR 
response with the F bit set to 1. The response frame returned by the DCE to an I frame 
or supervisory frame with the P bit set to 1, received during the disconnected phase, 
will be a DM response with the F bit set to l. 


The P bit may be used by the DCE in conjunction with the timer recovery condition (see 
2.4.5.9 below). 


XI uses the P bit in conjunction with the timer recovery condition as described in 
2.4.5.9 below. 


Note - Other use of the P bit by the DCE is a subject for further study. 


2.%.% LAPB Procedure for Link Set-up and Disconnection 


2.4.4.1 Link Set-up 


The DCE will indicate that it is able to set up the data link by transmitting 
continuous flags Cactive channel state). 


Eicher the DTE or the DCE may initiate Link set-up. Prior to initiation of link 

set-up, either the DCE or the DTE may initiate link disconnection (see 2.4.4.3) for 
the purpose of insuring that the DCE and the DTE are in the same phase. The DCE may 
also transmit an unsolicited DM response to request the DTE to initiate link set-up. 


Note that XI does not send SABM frames but uses the DM frame as just described. The 
DTE/DCE interface is activated by the network operator. This causes the physical 
level to be set-up. Then the DCE enters the "DCE disconnected" state and issues an 
unsolicited DM frame (with F-bit set to 0) as described in 2.4.4%.4.2, and activates 
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| the link channel towards the DTE (transmission of contiguous flags). The DCE is then 
| ready to accept link set-up by the DTE as described below. 


The DTE shall initiate link set-up by transmitting a SABM command to the DCE. If, 
upon receipt of the SABM command correctly, the DCE determines that it can enter the 
nformation transfer phase, it will return a UA response to the DTE, will reset its 
end and receive state variables V(S) and VCR) to zero, and will consider that the 
ink 1s set up. If, upon receipt of the SABM command correctly, the DCE determines 
that it cannot enter the information transfer phase, it will return a DM response to 
the DTE as a denial to the link set-up initialization and will consider that the link 
is not set up. In order to avoid misinterpretation of the DM response received, it 
1S suggested that the DTE always send its SABM command with the P bit set to 1. 
Otherwise, it is not possible to differentiate a DM response intended as a denial to 
link set-up from a DM response that is issued in a separate unsolicited sense as a 
request for a mode-setting command (Cas described in 2.4.4.4.2). 


In the "DCE disconnected” state, XI enters the information transfer phase (by sending 
a UA), if the level of resources (buffers) in the XI node is sufficient. Otherwise, 
a DM is returned to the DTE. 


| DCE initiated link set-up is not applicable in the XI environment. 


2.4.4.2 Information Transfer Phase 


After having transmitted the UA response to the SABM command or having received the 
UA response to a transmitted SABM command, the DCE will accept and transmit I and 
supervisory frames according to the procedures described in 2.4.5. 


When receiving the SABM command while in the information transfer phase, the DCE will 
conform to the link resetting procedure described in 2.4.7. 


2.4.%.3 Link Disconnection 


@:- DTE shall initiate a disconnect of the data link by transmitting a DISC command 

o the DCE. On correctly receiving a DISC command in the information transfer state, 
the DCE will send a UA response and enter the disconnected phase. On correctly 
receiving a DISC command in the disconnect phase, the DCE will send a DM response and 
remain in the disconnect phase. In order to avoid misinterpretation of the DM 
response received, it is suggested that the DTE always send its DISC command with the 
P bit set to 1. Otherwise, it is not possible to differentiate a DM response tntended 
as an indication that the DCE is already in the disconnected phase from a DM response 
that is issued in a separate unsolicited sense as a request for a mode-setting command 
Cas described in 2.4.4.4.2). 


The DCE will initiate a disconnect of the data link by transmitting a DISC command 
to the DTE and starting its Timer Tl (see 2.4.8.1). Upon reception of a UA response 
from the DTE, the DCE will stop its Timer Tl and will enter the disconnected phase. 
Upon reception of a DM response from the DTE as an indication that the DTE was already 
in the disconnected phase, the DCE will stop its Timer Tl and will enter the 
disconnected phase. 


The only case where XI initiates a disconnect is when the network operator sends a 
command deactivating the interface. The DISC frame is then sent with P bit set to 


@ 


The DCE, having sent the DISC command, will ignore and discard any frames except a 
SABM or DISC command, or a UA or DM response received from the DTE. The receipt of 
a SABM or DISC command from the DTE will result ina collision situation that is 
resolved per 2.4.4.5 below. 


After the DCE sends the DISC command, if a UA or DM response is not received correctly, 
Timer Tl will run out in the DCE. The DCE will then resend the DISC command and will 
restart Timer Tl. After transmission of the DISC command N2 times by the DCE, 
appropriate higher level recovery action will be initiated. The value of N2 is 
defined in 2.4.8.4 below. 
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2.4.4.% Disconnected Phase 


2.-4.4.4.1 After having received a DISC command from the DTE and returned a UA 
response to the DTE, or having received the UA response to a transmitted DISC command, 
the DCE will enter the disconnected phase. 


XI distinguishes two cases, depending whether the DISC has been sent by the DTE ("DTE 
disconnected" state) or by the DCE ("operator disconnected” state). The XI DCE may 
also transmit a DM frame Ce.g., after N2 unacknowledged I frames have been sent) and 


enter the "DCE disconnected state” (see 2.4.4.4.2). 


In the disconnected phase, the DCE may initiate link set-up. In the disconnected 
phase, the DCE will react to the receipt of an SABM command as described in 2.4.4.1 
above and will transmit a DM response in answer to a received DISC command. When 
receiving any other command (defined, or undefined or not implemented) with the P bit 
set to 1, the DCE will transmit a DM response with the F bit set to 1. Other frames 
received in the disconnected phase will be ignored by the DCE. 


XI never initiates link set-up. In the "DTE disconnected™ state or in the "DCE 
disconnected" state, the DCE will accept a SABM frame from the DTE (see 2.4.4.4.2). 


In the "operator disconnected” state, the DCE will not accept a SABM Ci.e., replies 
with a DM frame). 


2.4.4.4.2 When the DCE enters the disconnected phase after detecting error 
conditions as listed in 2.4.6 below, or after an internal malfunction, it may indicate 
this by sending a DM response rather than a DISC command. In these cases, the DCE 
will transmit a DM response and start its Timer Tl (see 2.4.8.1 below). 


When XI detects an error condition, it sends an unsolicited DM frame as described 
above, enters a "DCE disconnected" state, and accepts SABM frames from the DTE, as 
for the "DTE disconnected" state. 


If Timer Tl runs out before the reception of an SABM or DISC command from the DTE, 
the DCE will retransmit the DM response and restart Timer Ti. After transmission of 
the DM response N2 times, the DCE will remain in the disconnected phase and 


appropriate recovery actions will be initiated. The value of N2 is defined in 2.4.8.4 
below. 


After N2 transmissions of the DM frames, the XI DCE stays in the "DCE disconnected” 
state, waiting indefinitely for an SABM from the DTE or a deactivation of the 
interface by the network operator. No recovery procedure is initiated by the DCE. 


Alternatively, after an internal malfunction, the DTE may either initiate a link 
resetting procedure Csee 2.4.7 below) or disconnect the data link (see 2.4.4.3) prior 
to initiating a link set-up procedure (see 2.4.4.1 above). 


2.4.4.5 Collision of Unnumbered Commands 
Collision situations shall be resolved in the following way: 


2.4.4.5.1 If the sent and received unnumbered commands are the same, the DCE and 
DTE shall send the UA response at the earliest possible opportunity. The DCE shall 


enter the indicated phase either 1) After receiving the UA response, 2) After sending 


the UA response, or 3) After timing out waiting for the UA response having sent a UA 
response. In the case of 2) above, the DCE will accept a subsequent UA response to 
the mode-setting command it issued without causing an exception condition if received 
within the time-out interval. 


2-4.4.5.2 If the sent and received unnumbered commands are different, the DCE and 
DTE shall enter the disconnected phase and issue a DM response at the earliest 
possible opportunity. 


22 XI DTE/DCE Interface Description 


IBM Confidential 
2.4.4.6 Collision of DM Response With SABM or DISC Command 


| 
| When a DM response is issued by the DCE or DTE as an unsolicited response to request 
| the DTE or DCE, respectively, to issue a mode-setting command as described in 2.4.4.4, 
collision between a SABM or DISC command and the unsolicited DM response may occur. 
n order to avoid misinterpretation of the DM response received, the DTE always sends 
1ts SABM or DISC command with the P bit set to 1. 


2.4.4.7 Collision of DM Responses 


A contention situation may occur when both the DCE and the DTE issue a DM response 
to request a mode-setting command. In this case, the DTE will issue a SABM command 
to resolve the contention situation. 


2.4.5 LAPB Procedures for Information Transfer 


The procedures which apply to the transmission of I frames in each direction during 
the information transfer phase are described below. 


In the following, "number one higher” is in reference to a continuously repeated 
sequence series, 1.e., 7 1s 1 higher than 6 and 0 is 1 higher than 7 for modulo 8 
series, and 127 is 1 higher than 126 and 0 is 1 higher than 127 for modulo 128 series. 


2.4.5.1 Sending I Frames 


When the DCE has an I frame to transmit Ci.e., an I frame not already transmitted, 

or having to be retransmitted as described in 2.4.5.6), it will transmit it with an 
NCS) equal to its current sent state variable V(S), and an N(R) equal to its current 
receive state variable VCR). At the of the transmission of the I frame, the DCE will 


ee its send state variable VCS) by l. 


f Timer T1 is not running at the time of transmission of an I frame, it will be 
started. 


If the send state variable VCS) is equal to the last value of NCR) received plus k 
(where k is the maximum number of outstanding I frames see 2.4.8.6 below), the DCE 
Will not transmit any new I frames, but may retransmit an I frame as described in 
2.4.5.6 or 2.4.5.9 below. 


When the DCE is in the busy condition, it may still transmit I frames, provided that 
the DTE 1s not busy. When the DCE is in the frame rejection condition, it will stop 
transmitting I frames. 


2.4.5.2 Receiving an I Frame 


When the DCE is not tin a busy condition and receives a valid I frame whose send 
sequence number NCS) is equal to the DCE receive state variable V(R), the DCE will 
accept the information field of this frame, increment by one its receive state 
variable VCR), and act as follows: 


a. If the DCE is still not in a busy condition: 


1) If an I frame is available for transmission by the DCE, it may act as in 
2.4.5.1 above and acknowledge the received I frame by setting NCR) in the 
control field of the next transmitted I frame to the value of the DCE 
receive state variable VCR). Alternatively, the DCE may acknowledge the 
received I frame by transmitting an RR frame with the NCR) equal to the 
value of the DCE receive state variable VCR). 
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2) If no I frame is available for transmission by the DCE, it will transmit 
an RR frame with NCR) equal to the value of the DCE receive state variable 
VCR). 


1. If the DCE is now in a busy condition, it will transmit an RNR frame with NCR) 
equal to the value of the DCE receive state variable VCR) (see 2.4.5.8). 


When the DCE is in a busy condition, it may ignore the information field contained 
in any received I frame. 


When possible, XI acknowledges a received I frame using the NCR) field in an I frame 
transmitted to the DTE. 


XI ignores the information field of I frames received when in a busy condition, but 
takes into account the NCR) value. 


2.4.5.3 Reception of Invalid Frames 


When the DCE receives an invalid frame (see 2.3.5.3), this frame will be discarded. 


2.4.5.4 Reception of Out-of-sequence I Frames 


When the DCE receives a valid I frame whose send sequence number NCS) is incorrect, 
i.e., not equal to the current DCE receive state variable VCR), 1t will discard the 
information field of the I frame and transmit an REJ frame with the NCR) set to one 
higher than the NCS) of the last correctly received I frame. The REJ frame will be 
a command frame with the P bit set to 1 if an acknowledged transfer of the 
retransmitting request is required: otherwise the REJ frame may be a command or a 
response frame. The DCE will then discard the information field of all I frames 
received until the expected I frame is correctly received. When receiving the 
expected I frame, the DCE will then acknowledge the I frame as described in 2.4.5.2 
above. The DCE will use the NCR) and P bit information in the discarded I frames as 
described in 2.3.5.2 above. 


XI only sends REJ frames as response frames. 


2.4.5.5 Receiving Acknowledgment 


When correctly receiving an I frame or a supervisory frame (RR, RNR, or REJ), even 
in the busy condition, the DCE will consider the NCR) contained in this frame as an 
acknowledgment for all I frames it has transmitted with an NCS) up to and including 
the received NCR)-1. The DCE will stop Timer Tl when it correctly receives an I frame 
or a supervisory frame with the NCR) higher than the last received N(R) Cactually 


acknowledging some I frames), or a REJ frame with an NCR) equal to the last received 
NOR). 


If Timer Tl has been stopped by the receipt of an I, RR, or RNR frame, and if there 
are outstanding I frames still unacknowledged, the DCE will restart Timer Tl. If 
Timer Tl then runs out, the DCE will follow the recovery procedure (2.4.5.9) with 
respect to the unacknowledged I frames. If Timer Tl has been stopped by the receipt 
of a REJ frame, the DCE will follow the retransmitting procedures in 2.4.5.6 below. 


2.4.5.6 Receiving a REJ Frame 


When receiving a REJ frame, the DCE will set its send state variable V(S) to the NCR) 
received in the REJ control field. It will transmit the corresponding I frame as soon 
as it is available or retransmit it in accordance with the procedures described in 
2.4.5.1. (CRedtransmission will conform to the following procedure: 


1. If the DCE is transmitting a supervisory command or response when 1 t receives 


the REJ frame, it will complete that transmission before commencing transmitting 
of the requested I frame. 
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2. If the DCE is transmitting an unnumbered command or response when i t receives 
the REJ frame, it will ignore the request for retransmitting. 


| 3. XI does not abort frames. 


©. If the DCE is not transmitting any frame when the REJ frame is received, it will 
commence transmission of the request I frame immediately. 


In all cases, if other unacknowledged I frames had already been transmitted following 
the one indicated in the REJ frame, then those I frames will be retransmitted by the 
DCE following the retransmitting of the requested I frame. Other I frames not yet 
transmitted may be transmitted following the retransmitted I frames. 


If the REJ frame was received from the DTE as a command with the P bit set to 1, the 
DCE will transmit an RR, RNR or REJ response with the F bit set to 1 before 
transmitting or retransmitting the corresponding I frame. 


2.4.5.7 Receiving an RNR Frame 


After receiving an RNR frame, the DCE may transmit or retransmit the I frame with the 
send sequence number equal to the N(R) indicated in the RNR frame and start Timer Tl, 
if not already running. If Timer Tl runs out before receipt of a busy clearance 
indication, the DCE will follow the procedure described in 2.4.5.9 below. In any 
case, the DCE will not transmit any other I frames before receiving an RR or REJ frame, 
or before the completion of a link resetting procedure. 


Alternatively, after receiving an RNR frame, the DCE may wait for a period of time 
Ce.g., the length of the Timer T1)} and then transmit a supervisory command frame (RR, 
RNR or REJ) with the P bit set to 1, and start Timer Tl, in order to determine if there 
is any change in the receive status of the DTE. The DTE shall respond to the P bit 
set to 1 with a supervisory response frame (RR, RNR or REJ) with the F bit set to l 
indicating either continuance of the busy condition (RNR) or clearance of the busy 
condition (RR or REJ}. Upon receipt of the DTE response, Timer Tl is stopped. 


|} XI makes use of the second alternative, where the DCE issues an RR command with P bit 
et to 1 after a period equal to T1. It does so only if there are I frames waiting 
or acknowledgment on the DCE side. 


1. If the response is the RR or REJ response, the busy condition is cleared 
and the DCE may transmit I frames beginning with the I frame identified by 
the NCR) in the received response frame. , 


2. If the response is the RNR response, the busy condition still exists, and the 
DCE will after a period of time (Ce.g., the length of Timer Tl) 
repeat the enquiry of the DTE receive status. 


If Timer Tl runs out before a status response is received, the enquiry process above 
15 repeated. If N2 attempts to get a status response fail (Ci.e., Timer Tl runs out 
N2 times), the DCE will itnitiate a link resetting procedure as described in 2.4.7.2 
below or will transmit a DM response to ask the DTE to initiate a link set-up procedure 
as described in 2.4.4.1 and enter the disconnected phase. The value of N2 is defined 
in 2.4.8.4 below. 


If, at any time during the enquiry process, an unsolicited RR or REJ frame is received 
from the DTE, 1t will be considered to be an indication of clearance of the busy 
condition. Should the unsolicited RR or REJ frame be a command frame with the P bit 
set to 1 the appropriate response frame with the F bit set to 1 must be transmitted 
before the DCE may resume transmission of I frames. If Timer Tl is running, the DCE 
will wait for the non-busy response with the F bit set to 1, or will wait for Timer 
Tl to run out and then either may reinitiate the enquiry process in order to realize 
a successful P/F bit exchange or may resume transmission of I frames beginning with 
the I frame identified by the NCR) tn the received RR or REJ frame. 


| When the busy condition is cleared by the DTE, XI immediately resumes the transmission 
| of any pending I frames. 
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2.4.5.8 DCE Busy Condition 


When the DCE enters a busy condition, it will transmit an RNR frame at the earliest 
opportunity. The RNR frame will be a command frame with the P bit set to 1 if an 
acknowledged transfer of the busy condition indication is required: otherwise the RNR 
frame may be either a command or a response frame. While in the busy condition, the 
DCE will accept and process supervisory frames, will accept and process the controls 
of the NCR) fields of I frames, and will return an RNR response with the F bit set 
to 1 if it receives a supervisory command or I command frame with the P bit set to 
1. To clear the busy condition, the DCE will transmit either a REJ frame or a RR 
frame, with NCR) set to the current receive state variable V(R), depending on whether 
or not it discarded information fields of correctly received I frames. The REJ frame 
or the RR frame or the frame will be a command frame with the P bit set to 1 if an 
acknowledged transfer of the busy-to-non-busy transition is required, otherwise the 
REJ frame or the RR frame may be either a command or a response frame. 


XI may enter a busy condition when the level of resources of the XI node (buffers) 
goes under a threshold defined by the network service provider. 


XI will enter a busy condition when modem or line tests are run, at the request of 
the network operator. 


2.4.5.9 Waiting Acknonledgment 


The DCE maintains an internal transmission attempt variable which is set to 0 when 
the DCE sends a UA response, when the DCE receives a UA response or an RNR command 
or response, or when the DCE correctly receives an I frame or supervisory frame with 
the NCR) higher than the last received N(R) Cactually acknowledging some outstanding 
I frames). 


If Timer Tl runs out waiting for the acknowledgment from the DTE for an I frame 
transmitted, the DCE will enter the Timer recovery condition, add one to its 
transmission attempt variable and set an internal variable x to the current value of 
its send state variable V(S). 


The DCE will restart Timer Tl, set its send state variable VCS) to the value of NCR) 
received from the DTE and retransmit the corresponding I frame with the P bit set to 


1, or transmit an appropriate supervisory command frame CRR, RNR or REJ) with the P 
bit set to l. 


XI makes use of the second method, i.e. issues a supervisory command (Cin principle 
an RR command) with the P bit set to l. 


The timer recovery condition is cleared when the DCE receives a valid supervisory 
frame with the F bit set to l. 


If, while in the timer recovery condition, the DCE correctly receives a supervisory 
frame with the F bit set to 1 and with the NCR) within the range from its current send 
state variable V(S) to x included, 1t will clear the timer recovery condition 
Cincluding stopping Timer T1) and set its send state variable V(S) to the value of 
the received NCR), and may then resume with I frame transmission or retransmitting, 
as appropriate. 


If, while in the timer recovery condition, the DCE correctly receives an I or 
supervisory frame with the P/F bit set to 0 and with a valid NCR) (Csee 2.3.4.9), it 
will not clear the timer recovery condition. The value of the received NCR) may be 
used to update the send state variable V(S). 


XI accepts the NCR) information of a frame with the F bit set to 0 when it is in timer 
recovery condition. 


If the received supervisory frame with the P/F bit set to 0 is a REJ frame with a valid 
NCR, the DCE may either immediately initiate Cre)Jtransmission from the value of the 
send state variable V(S), or it may ignore the request for retransmission and wait 
until the supervisory frame with the F bit set to 1 is received before initiating 
CredJtransmission of frames from the value identified in the NCR) field of the F=l 
supervisory frame. 


XI waits for a supervisory frame with the F bit set to 1 before resuming the 
transmission of I frames. 
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If, while in the timer recovery condition, the DCE receives a REJ command with the P 
bit set to 1, the DCE will respond immediately with an appropriate supervisory 

response with the F bit set to 1. The DCE may then use the value of the N(R) in the 
REJ command to update the send state variable V(S), and may either immediately begin 
Credtransmission from the value NCR) indicated in the REJ frame or ignore the request 


@:: retransmitting and wait until the supervisory frame with the F bit set to 1 is 


eceived before initiating Cre)Jtransmission of I frames the value identified in the 
CR) field of the F = 1 supervisory frame. 


XI waits for a supervisory frame with the F bit set to 1 before resuming the 
transmission of I frames. 


If Timer Tl runs out in the timer recovery condition, and no I supervisory frame with 
the P/F bit set to 0 and a valid NCR) has been received, or no REJ command with the 
P bit set to 1 and with a valid NCR) has been received, the DCE will add one to its 
transmission attempt variable, restart Timer Tl, and either retransmit the I frame 


sent with the P bit set to 1 or transmit an appropriate supervisory command with the 
P bit set to 1. 


XT makes use of the second method, i.e., issues a supervisory command with the P bit 
se o 1. 


If the transmission attempt variable is equal to N2, the DCE will initiate a link 
resetting procedure as described tn 2.4.7.2 below, or will transmit a DM response to 
ask the DTE to initiate a link set-up procedure as described in 2.4.4.1 and enter the 
disconnected phase. N2 is a system parameter (see 2.4.8.4). 

XI makes use of the second method, i.e., 1tssues a DM frame and enters the "DCE 
disconnected" state, where it accepts an SABM or DISC from the DTE. 


Note - Although the DCE may implement the internal variable X, other mechanisms do 
exist that achieve the identical function. 


2.4.6 LAPB Conditions for Link Resetting or Link Re-initialization (Link Set-up) 


2.4.6.1 When the DCE receives, during the information transfer phase, a frame which 


@' not invalid Csee 2.4.5.3) with one of the conditions listed in 2.3.4.9, the DCE 


ill request the DTE to initiate a link resetting procedure by transmitting an FRMR 
response to the DTE as described in 2.4.7.3. 


2.4.6.2 When the DCE receives, during the information transfer phase, an FRMR 
response from the DTE, the DCE will either initiate the link resetting procedure 
itself as described in 2.4.7.2 or return a DM response to ask the DTE to initiate the 
link set-up Cinitialization) procedure as described in 2.4.4.1. After transmitting 
a DM response, the DCE will enter the disconnected phase as described in 2.4.4.4%.2. 


XI makes use of the second method, i.e., issues a DM frame and enters the "DCE 
disconnected" state, where it accepts a SABM or DISC from the DTE. 


2.4.6.3 When the DCE receives, during the information transfer phase, a UA 
response, or an unsolicited response with the F bit set to 1, the DCE may either 
initiate the link resetting procedure itself as described in 2.4.7.2, or return a DM 
response to ask the DTE to initiate the link set-up Cinitialization) procedure as 
described in 2.4.4.1. After transmitting a DM response, the DCE will enter the 
disconnected phase as described in 2.4.4.2. 

XI makes use of the second method, i.e., issues a DM frame and enters the "DCE 
disconnected" state, where it accepts a SABM or DISC from the DTE. 


2.4.6.4 When the DCE receives, during the information transfer phase, a DM response 
from the DTE, the DCE will either initiate the link set-up Cinitialization) procedure 
itself as described in 2.4.4.1, or return a DM response to ask the DTE to initiate 
the link set-up Cinitialization) procedures as described in 2.4.4.1. After 
transmitting a DM response, the DCE will enter the disconnected phase as described 
in 2.4.4.4.2. 


XI makes use of the second method, ji.e., issues a DM frame and enters the "DCE 


o-7™ state, where 1t accepts a SABM or DISC from the DTE. 
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2.4.7 LAPB Procedure for Link Resetting 


2.4.7.1 The link resetting procedure is used to initialize both directions of 
information transfer according to the procedure described below. The link resetting 
procedure only applies during the information transfer phase. 


2.4.7.2 Either the DTE or the DCE may initiate the link resetting procedure. The 
link resetting procedure indicates a clearance of a DCE and/or DTE busy condition, 
if present. 


The DTE shall initiate a link resetting by transmitting a SABM command to the DCE. 
If, upon receipt of the SABM command correctly, the DCE determines that it can 
continue in the information transfer phase, it will return a UA response to the DTE, 
will reset its send and receive state variable V(S) and VCR) to zero, and will remain 
in the information transfer phase. If, upon receipt of the SABM command correctly, 
the DCE determines that it cannot remain 1 n the information transfer phase, it 
will return a DM response as a denial to the resetting request and will enter the 
disconnected phase. 


XI accepts a SABM or DISC command from the DTE except in the "operator disconnected” 
state. XI never sends SABM but issues DM, enters the "DCE disconnected" state, and 
accepts a SABM or DISC from the DTE. 


DCE initiated link resetting is not applicable in the XI environment. 


2.4.7.3 The DCE may ask the DTE to reset the data link by transmitting an FRMR 
response (see 2.4.6.1 above). 


After transmitting an FRMR response, the DCE will enter the frame rejection condition. 
The frame rejection condition is cleared when the DCE receives or transmits an SABM 
or DISC command or a DM response - <Any other command received while in the frame 
rejection condition will cause the DCE to retransmit the FRMR response with the same 
information field as originally transmitted. 


The DCE may start Timer Tl on transmission of FRMR response. If Timer Tl runs out 
before the reception of an SABM or DISC command or a DM response from the DTE, the 
DCE may retransmit the FRMR response, and restart Timer Tl. After N2 attempts to get 
the DTE to reset the link, the DCE may reset the link itself as described in 2.4.7.2. 
The value of N2 is defined in 2.4.8.4 below. 


The FRMR response is not repeated by XI. At the expiry of timer Tl, a DM frame is 
sent to the DTE and the interface goes into the "DCE disconnected” state. 


In the frame rejection condition, I frames and supervisory frames will not be 
transmitted by the DCE. Also, received I frames and supervisory frames will be 
discarded by the DCE except for the observance of a P bit set to 1. When an additional 
FRMR response must be transmitted by the DCE as a result of the receipt of a P bit 
set to 1 while Timer T1 1s running, Timer T1 will continue to run. Upon reception 
of an FRMR response Ceven during a frame rejection condition), the DCE will initiate 
a resetting procedure by transmitting an SABM command as described in 2.4.7.2, or will 
transmit a DM response to ask the DTE to initiate the link set-up procedure as 
described in 2.4.4.1 and enter the disconnected phase. 


XI makes use of the second method, 1.e., issues a DM frame and enters the "DCE 
disconnected” state, where it accepts a SABM or DISC from the DTE. 


2.%.8 List of LAPB System Parameters 


The DCE and DTE system parameters are as follows: 


2.4.8.1 Timer Tl 


The value of the DTE Timer Tl system parameter may be different than the value of the 
DCE Timer Tl system parameter. These values shall be made known to both the DTE and 
the DCE, and agreed to for a period of time by both the DTE and the DCE. 
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The DCE timer T1 may be chosen at subscription time between 0.5 sec and 6 sec. The 


corresponding DTE timer Tl is not known by XI but should preferably be chosen close 
to the DCE timer Tl. 


The period of Timer Tl, at the end of which retransmitting of a frame may be initiated 


see 2.4.4 and 2.4.5 above for the DCE), shall take into account whether Tl is started 
t the beginning or the end of transmission of a frame. . 


[| XI starts timer Tl at the end of the transmission of a frame. 


The proper operation of the procedure requires that the transmitter'"s (DCE or DTE) 
Timer Tl be greater than the maximum time between transmission of a frame (SABM, DISC, 
I or supervisory command, or DM or FRMR response) and the reception of the 
corresponding frame returned as an answer to that frame (UA, DM or acknowledging 
frame). Therefore, the receiver (DCE or DTE) should not delay the response or 
acknowledging frame returned to one of the above frames by more than a value T2, where 
T2 18S a system parameter (see 2.4.8.2). 


The DCE will not delay the response or acknowledging frame returned to one above DTE 
frames by more than a period T2. 


2.4.8.2 Parameter T2 


The value of the DTE parameter T2 may be different than the value of the DCE parameter 
T2. These values shall be made know to both the DTE and the DCE, and agreed to for 
a period of time by both the DTE and the DCE. 


The peritod of parameter T2 shall indicate the amount of time available at the DCE 
before the acknowledging frame must be initiated in order to ensure its receipt by 


the DTE or DCE, respectively, prior to Timer Tl running out at the DTE or DCE. T2 < 
T1. 


Note: The period of parameter T2 shall take into account the following timing 
factors: the transmission time of the acknowledging frame, the propagation time over 
the access link, the stated processing times at the DCE and the DTE, and the time to 
complete the transmission of the frame (S) in the DCE or DTE transmit queue that are 
neither displaceable or modifiable in an orderly manner. 


iven a value for Timer Tl for the DTE or DCE, the value of parameter T2 at the DCE 
@- DTE, respectively, must be no larger than Tl minus 2 times the propagation time 
over the access link, minus the frame processing time at the DCE, minus the frame 
processing time at the DTE, and minus the transmission time of the acknowledging frame 
by the DCE or DTE, respectively. 


| The DCE timer T2 is optional. It may be chosen at subscription time between 0.5 sec 
| and 6 sec. 
2.4.8.3 Timer T3 
The timer T3 1s not implemented in the XI DCE, ji.e., the DTE may consider that T3 has 
an infinite value. 
2.4.8.4 Maximum Number of Attempts to Complete a Transmission N2 
The value of the DTE N2 system parameter may be different than the value of the DCE 
N2 system parameter. These values shall be made known to both the DTE and the DCE, 
and agreed to for a period of time by both the DTE and the DCE. 


The value of N2 shall indicate the maximum number of attempts made by the DCE or DTE 
to complete the successful transmission of a frame to the DTE or DCE, respectively. 


| The DCE value of parameter N2 can be chosen from between 3 and 31, independently per 
access port. XI does not act upon the DTE value of the N2 parameter, which 1s not a 
| parameter of the access port. 


2.4.8.5 Maximum Number of Bits in an I Frame Nl 


The value of the DTE Nl system parameter may be different than the value of the DCE 
Ni system parameter. These values shall be known to both the DTE and the DCE. 
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The values of NL shall indicate the maximum number of bits in an I frame Cexcluding 
flags and 0 bits inserted for transparency) that the DCE or the DTE is willing to 
accept from the DTE or DCE respectively. 


In order to allow for universal operation, a DTE should support a value of DTE Nl which 
is not less than 1090 bits (135 octets). DTE should be aware that the network may 
transmit longer packets (see 5.2), that may result ina link level problem. 


All networks shall offer to a DTE which requires it a value of DCE Ni which is greater 
than or equal to 2092 bits (259 octets) plus length of the address, control and FCS 

fields at the DTE/DCE interface, and greater than or equal to the maximum length of 

the data packets which may cross the DTE/DCE interface plus the length of the address, 
control and FCS fields at the DTE/DCE interface. 


The link level of XI accepts frames whose length includes the maximum packet size plus 
the headers of link and packet levels. Too large packets are handled at packet level 
according to the procedures in 4 and 5. 


2.4.8.6 Maximum Number of Outstanding I Frames K 


The value of the DTE K system parameter shall be the same as the DCE K system 
parameter. This value shall be agreed to for a period of time by both the DTE and 
DCE. 


The value of K shall indicate the maximum number of sequentially numbered I frames 
that the DTE or DCE may have outstanding (1.e., unacknowledged) at any given time. 
The value of K shall never exceed seven for Modulo 8 operation, or one hundred twenty 
seven for Modulo 128 operation. All networks (DCEs) shall support a value of seven. 


Other values of K (less than and greater than seven) may also be supported by networks 
CDCEs). 


For XI, K can be chosen between 1 and 7 with modulo 8. Modulo 128 is not applicable 
in the XI environment. 

2.4.8.7 Inactivity Timer Ti 

The timer Ti, specific to XI, need not be known or implemented by the DTE. XI DCE 
starts timer Ti when it is in data transfer phase, has no frame to transmit, and has 
no outstanding frame (waiting for acknowledgement). This permits checking that the 


DTE stays logically connected with the DCE, even in the absence of traffic. 


Ti 15S optional. Ti can be subscribed between 1 and 400 seconds, and should be larger 


than Tl. The XI DCE stops timer Ti when it has a frame to transmit or has received 
a frame. 


Upon a time-out of timer Ti, XI DCE sends an RR command with P bit set to 1, which 
should be replied by the DTE with an RR or RNR response, with F bit set to l. 


2.5 MULTILINK PROCEDURE (MLP) (SUBSCRIPTION-TIME SELECTABLE OPTION) 


Multilink procedure (MLP) is not applicable in the XI environment. 


2.6 LAP ELEMENTS OF PROCEDURE 


Lap elements of procedure are not applicable in the XI environment. 
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3. DESCRIPTION OF THE PACKET LEVEL DTE/DCE INTERFACE 


This and subsequent points of the Recommendation relate to the transfer of packets 


@- the DTE/DCE interface. The procedures apply to packets which are successfully 


ransferred across the DTE/DCE interface. 


Each packet to be transferred across the DTE/DCE interface shall be contained within 
the link level information field which will delimit its length, and only one packet 
shall be contained in the information field. 


XI requires that packets contain an integral number of octets. 


If XI receives from the DTE a packet not containing an integral number of octets, the 
frame containing the packet is discarded. 


DTEs wishing universal operation on all networks should transmit all packets with data 
fields containing only an integral number of octets. Full data integrity can only 
be assured by exchange of octet-oriented data fields in both directions of 
transmission. 


This point covers a description of the packet level interface for virtual call and 
permanent virtual circuit services. As designated in Recommendation X.2, virtual call 
and permanent virtual circuit services are essential (CE) services to be provided by 
all networks. 


Procedures for the virtual circuit service (that is, virtual call an d permanent 


virtual circuit services) are specified in 4. Packet formats are specified in 5. 
Procedures and formats for optional user facilities are specified in 6 and 7. 


3.1] LOGICAL CHANNELS 


To enable simultaneous virtual calls and/or permanent virtual circuits, logical 
channels are used. Each virtual call or permanent virtual circuit 1s assigned a 
logical channel group number (less than or equal to 15) and a logical channel number 


logical channel number are assigned during the call set-up phase. The range of 


@ ::: than or equal to 255). For virtual calls, a logical channel group number and 


ogical channels used for virtual calls is agreed with the Administration at the time 
of subscription to the service (see Annex A). For permanent virtual circuits, logical 
channel group numbers and logical channel numbers are assigned in agreement with the 
Administration at the time of subscription to the service (see Annex A). 


3.2 BASIC STRUCTURE OF PACKETS 


Every packet transferred across the DTE/DCE interface consists of at least three 
octets. These three octets contain a general format identifier, a logical channel 
identifier and a packet type identifier. Other packet fields are appended as required 
(see 5). 
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Packet types and their use in association with various services are given in Table 
14/X.25. 
TABLE 147X.25 


Packet Types and their Use in Various Services @ 


From DCE to DTE From DTE to DCE PVC 
CALL SET-UP AND CLEARING (see Note 1) 


Incoming call Call request 

Call connected Call accepted 

Clear indication Clear request 

DCE clear confirmation DTE clear confirmation 


DATA AND INTERRUPT (see Note 2) 


data DTE data 
interrupt DTE interrupt 
interrupt confirmation DTE interrupt confirmation 


FLOW CONTROL AND RESET Csee Note 3) 


DCE RR DTE RR 
DCE RNR DTE RNR 
DTE REJ Ca) 
Reset indication DTE request 
DCE reset confirmation DTE reset confirmation 


RESTART (see Note 4) 


Restart tndication Restart request 
DCE restart confirmation DTE restart confirmation 


DIAGNOSTIC (see Note 5) 


Diagnostic (Ca) 
REGISTRATION Ca)(€see Note 6) 


Registration confirmation 
Registration request 


Ca) Not necessarily available on all networks. 


VC Virtual call 
PVC Permanent virtual circuit 


Note 1 - See 4.1 and 6.16 for procedures, 5.2 for formats. 
Note 2 - See 4.3 for procedures and 5.3 for formats. 
Note 3 - See 4.4 and 6.4 for procedures, 5.4 and 5.7.1 for formats. 
Note 4 - See 3.3 for procedures and 5.5 for formats. 
Note 5 - See 3.4 for procedures and 5.6 for formats. 


Note 6 - See 6.1 for procedures and 5.7.2 for formats. 
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XI does not offer the packet retransmission additional facility, thu s the DTE REJ 
packet 1s not handled. 


XI does not offer the online registration facility, thus registration request and 
registration confirmation packets are not handled. 


-3_ PROCEDURE FOR RESTART 


The restart procedure is used to initialize or re-initialize the packet level DTE/DCE 
interface. The restart procedure simultaneously clears all the virtual calls and 
resets all the permanent virtual circuits at the DTE/DCE interface (see 4.5). 


Figure B-1/X.25 gives the state diagram which defines the logical relationships of 
events related to the restart procedure. 


Table C-2/X.25 specifies actions taken by the DCE on the receipt of packets from the 
DTE for the restart procedure. 


3.3.1 Restart by the DTE 


The DTE may at any time request a restart by transferring across the DTE/DCE interface 
a restart request packet. The interface for each logical channel is then in the DTE 
restart request state (r2). 


The DCE will confirm the restart by transferring a DCE restart confirmation packet 
and placing the logical channels used for virtual calls in the ready state (pl), and 


the logical channels used for permanent virtual circuits in the flow control ready 
state (dl). 


Note - States pl and di are specified in 4. 


The DCE restart confirmation packet can only be interpreted universally as having 
local significance. The time spent in the DTE restart request state (r2) will not 


eo time-limit T20 Csee Annex D). 


3.3.2 Restart by the DCE 


The DCE will indicate a restart by transferring across the DTE/DCE interface a restart 
indication packet. The interface for each logical channel is then in the DCE restart 
indication state (r3). In this state of the DTE/DCE interface, the DCE will ignore 
all packets except for restart request and DIE restart confirmation. 


The DTE will confirm the restart by transferring a DIE restart confirmation packet 
and placing the logical channels used for virtual calls in the ready state (pl), and 


the logical channels used for permanent virtual circuits in the flow control ready 
state (dl). 


The action taken by the DCE when the DTE does not confirm the restart within time-out 
T10 18S given in Annex D. 


An XI node initiates a restart procedure each time the link level is set up or 
re-initialized. With LAPB, a restart procedure is initiated after each complete 
exchange of SABM and UA frames. Moreover, an XI node also initiates a restart 
procedure in case of a procedure error from the DTE, as described in Annex C. 


3.3.3 Restart Collision 


Restart collision occurs when a DTE and a DCE simultaneously transfer a restart 
request and a restart indication packet. Under these circumstances, the DCE will 
consider that the restart is completed. The DCE will not expect a DTE restart 
confirmation packet and will not transfer a DCE restart confirmation packet. This 


r on the logical channels used for virtual calls in the ready state (pl), and the 
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logical channels used for permanent virtual circuits in the flow control ready state 
(di). 


3-4 ERROR HANDLING 


Table C-1/X.25 specifies the reaction of the DCE when special error conditions are 
encountered. Other error conditions are discussed in 4. 


3.4.1 Diagnostic Packet 


The diagnostic packet is used by some networks to indicate error conditions under 
circumstances where the usual methods of indication (that is, reset, clear and restart 
with cause and diagnostic) are inappropriate (see Tables C-1/X.25 and D-1/X.25). The 
diagnostic packet from the DCE supplies information on error situations which are 
considered unrecoverable at the packet level of Recommendation X.25; the information 
provided permits an analysis of the error and recovery by higher levels at the DTE 
if desired or possible. 


A diagnostic packet is issued only once per particular instance of an error 
condition. No confirmation is required to be issued by the DTE on receipt of a 
diagnostic packet. 


XI makes use of the diagnostic packet to report error conditions to the DTE, as 
described above. 


3.5 EFFECTS OF THE PHYSICAL LEVEL AND THE LINK LEVEL ON THE PACKET LEVEL 


Changes of operational states of the physical level and the link level of the DTE/DCE 
interface do not implicitly change the state of each logical channel at the packet 
level. Such changes when they occur are explicitly indicated at the packet level by 
the use of restart, clear or reset procedures as appropriate. 


A failure on the physical and/or link level is defined as a condition in which the 


DCE cannot transmit or cannot receive any frame because of abnormal conditions caused 
by, for instance, a line fault between DTE and DCE. 


When a failure on the physical and/or link level is detected, the DCE will clear 
virtual calls and reset permanent virtual circuits. Further actions are specified 
in 4.6 


In other out of order conditions on the physical and/or link level, the DCE will also 
clear virtual calls and reset permanent virtual circuits. An out of order condition 
on the link level includes receipt of a DISC command or transmission of a DISC command 
by the DCE, in the case of a single link procedure. 


When a failure or out of order condition is recovered at physical and link levels, 
the DCE will send a restart indication packet with the cause "Network operational" 
to the local DTE. Further actions are specified in 4.6. 


When XI has to clear virtual calls and reset permanent virtual circuits because of a 
change at the link level or at the physical level, the diagnostic code associated with 
the cause code "out of order™ permits the remote DTEs to be aware that they can resume 
communications with that DTE. The diagnostic code indicates one of the following 
situations: 


° The link level has not been initiated by the DTE, or a restart indication is 
pending. 
° A failure of the line or modems has been detected. 


° A DISC or DM frame has been received from the DTE. 


e The DTE/DCE interface has been deactivated by the network operator (CDISC has been 
sent by the DCE). 
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| A SABM frame has been received by the DCE to reinitiate the link level. 


e A DM frame has been sent by the DCE, for example; this happens when the maximum 
number of retransmissions 1s reached or on receiving an FRMR frame from the DTE. 


Moreover, the packet level of XI stores the last significant event at the link level 
r at the physical level, in order to respond with the same diagnostics to further 
call attempts or transmission attempts on a PVC. 


| The codes of such XI specific diagnostics are given in Annex E. 
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4. PROCEDURES FOR VIRTUAL CIRCUIT SERVICES 


4.1 PROCEDURES FOR VIRTUAL CALL SERVICE 


Figures B-1/X.25, B-2/X.25 and B-3/X.25 show the state diagrams which define the 
events at the packet level DTE/DCE interface for each logical channel used for virtual 
calls. 


Annex C gives details of the action taken by the DCE on receipt of packets in each 


state shown in Annex B. 


The call set-up and clearing procedures described in the following points apply 
independently to each logical channel assigned to the virtual call service at the 
DTE/DCE interface. 


4.1.1 Ready State 


If there is no call in existence, a logical channel is in the ready state (pl). 


6.1.2 Call Request Packet 


The calling DTE shall indicate a call request by transferring a call request packet | 
across the DTE/DCE interface. The logical channel selected by the DTE is then in the 
DIE waiting state (p2). The call request packet includes the called DTE address. 
The calling DTE address field may also be used. 


Note 1 - A DTE address may be a DTE network address or any other DTE identification 
agreed for a period of time between the DTE and the DCE. 


Note 2 - The call request packet should use the logical channel in the ready state 
with the highest number in the range which has been agreed @ 
with the Administratton (see Annex A). Thus the risk 
of call collision is minimized. 


For XI, the DTE is not required to fill the calling DTE address field, which avoids 
the constraint on the DTE to record its own address. In this case, the calling DTE 
address is inserted by the XI node. The DTE is nevertheless allowed to give its own 
address, a portion of its address, or one of its addresses when more than one address 
has been assigned to that DTE. 


The format and the semantics of the addresses that DTEs can handle must be in 
compliance with XI rules and with the addressing scheme of the XI network which is . 
the responsibility of the network service provider. Possible address formats for XI > 
are quoted in 5.8. 


4.1.3 Incoming Call Packet 


The DCE will indicate that there is an tncoming call by transferring across the 
DTE/DCE interface an incoming call packet. This places the logical channel in the 
DCE waiting state (p3). 


The incoming call packet will use the logical channel in the ready state with the 
lowest number (see Annex A). The incoming call packet includes the calling DTE 
address. The called DTE address field may also be used. 


Note: <A DTE address may be a DTE network address or any other DTE identification 
agreed for a period of time between the DTE and the DCE. 


In an incoming call packet, the XI node gives both the calling DTE address and the 
called DTE address. The called DTE address must be one of the addresses that have 
been assigned to that DIE. Possible address formats for XI are quoted in 5.8. 
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4.1.4 Call Accepted Packet 


The called DTE shall indicate its acceptance of the call by transferring across the 
DTE/DCE interface a call accepted packet specifying the same logical channel as that 


f the incoming call packet. This places the specified logical channel in the data 
ransfer state (p4). 


If the called DTE does not accept the call by a call accepted packet or does not reject 
it by a clear request packet as described in 4.1.7 within time-out Til (see Annex D), 
the DCE will consider it as a procedure error from the called DTE and will clear the 
virtual call according to the procedure described in 4.1.8. 


4.1.5 Call Connected Packet 


The receipt of a call connected packet by the calling DTE specifying the same logical 
channel as that specified in the call request packet indicates that the call has been 
accepted by the called DTE by means of a call accepted packet. This places the 
specified logical channel in the data transfer state (p4). 


a time spent in the DTE waiting state (p2) will not exceed time-limit T21 (see Annex 


4.1.6 Call Collision 


Call collision occurs when a DTE and DCE simultaneously transfer a call request packet 
and an incoming call packet specifying the same logical channel. The DCE will proceed 
with the call request and cancel the incoming call. 


4.1.7 Clearing by the DTE 


t any time, the DTE may indicate clearing by transferring across the DITE/DCE 
interface a clear request packet (see 4.5). The logical channel is then in the DTE 
clear request state (p6). When the DCE is prepared to free the logical channel, the 
DCE will transfer across the DTE/DCE interface a DCE clear confirmation packet 
specifying the logical channel. The logical channel is then in the ready state (pl). 


The DCE clear confirmation packet can only be interpreted universally as having local 
significance; however, within some Administrations’ networks, clear confirmation may 
have end-to-end significance. In all cases, the time spent in the DTE clear request 
state (p6) will not exceed time-limit T23 (see Annex D). 


| For XI, the DCE clear confirmation packet has a local significance. When the DCE 

| receives a DTE clear request, it immediately issues the DCE clear confirmation and 

| forwards the clear request, so that the logical channel returns to state Pl without 
delay. 


It is possible that subsequent to transferring a clear request packet the DTE will 
receive other types of packets, depending upon the state of the logical channel, 
before receiving a DCE clear confirmation packet. 


Note - The calling DTE may abort a call by clearing it before it has received a call 
connected or clear indication packet. 


The called DTE may refuse an incoming call by clearing it as described in this point 
rather than transmitting a call accepted packet as described in 4.1.4. 


4.1.8 Clearing by the DCE 


The DCE will indicate clearing by transferring across the DITE/DCE interface a clear 
indication packet (see 4.5). The logical channel is then in the DCE clear indication 
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state (p6). The DTE shall respond by transferring across the DTE/DCE interface a DTE 
clear confirmation packet. The logical channel is then in the ready state (pl). 


The action taken by the DCE when the DTE does not confirm clearing within time-out 
T13 is given in Annex D. 


4.1.9 Clear Collision 


Clear collision occurs when a DTE and DCE simultaneously transfer a clear request 
packet anda clear indication packet specifying the same logical channel. Under these 
circumstances the DCE will consider that the clearing 1s completed. The DCE will not 


expect a DTE clear confirmation packet and will not transfer a DCE clear confirmation 


packet. This places the logical channel in the ready state (pl). 


4.1.10 Unsuccessful Call 


If a call cannot be established, the DCE will transfer a clear indication packet 
specifying the logical channel indicated itn the call request packet. 


4.1.11 Call Progress Signals 


The DCE will be capable of transferring to the DTE clearing call progress signals as 
specified in Recommendation X. 96. 


Clearing call progress signals will be carried in clear indication packets which will 


terminate the call to which the packet refers. The method of coding clear indication 


packets containing call progress signals is detailed in 5.2.3. 


4.1.12 Data Transfer State 


The procedures for the control of packets between DTE and DCE while in the data 
transfer state are contained in 4.3. 


4.2 PROCEDURES FOR PERMANENT VIRTUAL CIRCUIT SERVICE 


Figures B-1/X.25 and B-37X.25 show the state diagrams which give a definition of 
events at the packet level DTE/DCE interface for logical channels assigned for 
permanent virtual circuits. 


Annex C gives details of the action taken by the DCE on receipt of packets in each 
state shown in Annex B. 


For permanent virtual circuits there is no call set-up or clearing. The procedures 
for the control of packets between DTE and DCE while in the data transfer state are 
contained in 4.3. 


If a momentary failure occurs within the network, the DCE will reset the permanent 
virtual circuit as described in 4.4.3, with the cause "Network congestion", and then 
will continue to handle data traffic. 


If the network has a temporary inability to handle data traffic, the DCE will reset 
the permanent virtual circuit with the cause "Network out of order”. When the network 
1S again able to handle data traffic, the DCE should reset the permanent virtual 
circuit with the cause "Network operational”. 


For XI, a PVC installation requires first that DCE tables be installed at both ends 
of the PVC; and secondly that the PVC be activated through an appropriate network 

operator command (PVC activation). As long as the PVC is not activated, XI reacts 
as for a temporary inability to handle data traffic, with a cause "out of order" if 
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the DTE has subscribed to the "X.25 1980" parameter, or "network out of order" if the 
DTE has subscribed to the "X.25 1984" parameter, and an XI specific diagnostic "PVC 
not activated"™. 


Once the PVC is activated, XI will try to establish and maintain the PVC, 
andependently of the status of the access links of the DTEs. Each time the status 

f one of the DTE access links is reversed so as to permit data transfer, a DCE reset 
indication is prepared with the cause “remote DTE operational” and the diagnostic is 
set to zero to inform the other DTE. This indication is transmitted to the DTE if 
the status of the access link permits it. 


| 

| 

| In the case where the DTE access link is not in the ready state, or at any time when 
| the DTE access link is turned to a status which does not permit data transfer, a DCE 
| reset indication is prepared with the cause "out of order" and an XI specific 

| diagnostic "remote access link not operational" to inform the remote DTE. This 

| indication may or not be transmitted to the DTE, depending on the status of the access 
{ link, and no further indications are given to the DTEs until there is a change in the 
| status of one of the access Links, or a network failure. 

| 
| 
| 


A PVC can be deactivated through a network operator command. Both DTEs will receive 
Cif the access link permits it) a DCE reset indication with the cause "out of order", 
and the XI specific diagnostic "PYC not activated". 


4.3 PROCEDURES FOR DATA AND INTERRUPT TRANSFER 


The data transfer and interrupt procedures described in this section apply 
independently to each logical channel assigned for virtual calls or permanent virtual 
circuits existing at the DTE/DCE interface. 


Normal network operation dictates that user data in data and interrupt packets are 
all passed transparently, unaltered through the network in the case of packet DTE to 
packet DTE communications. The order of bits in data and interrupt packets is 
preserved. Packet sequences are delivered as complete packet sequences. DTE 
diagnostic codes are treated as described in 5.2.3, 5.4.3 and 5.5.1. 


-3-1 States for Data Transfer 


A virtual call logical channel is tin the data transfer state (p4) after completion 
of call establishment and prior to a clearing or a restart procedure. A permanent 
virtual circuit logical channel is continually in the data transfer state (p44) except 
during the restart procedure. Data, interrupt, flow control and reset packets may 
be transmitted and received by a DTE in the data transfer state of a logical channel 
at the DTE/DCE interface. In this state, the flow control and reset procedures 
described in 4.4% apply to data transmission on that logical channel to and from the 
DTE. 


When a virtual call is cleared, data and interrupt packets may be discarded by the 
network (see 4.5). In addition, data, interrupt, flow control and reset packets 
transmitted by a DTE will be ignored by the DCE when the logical channel is in the 
DCE clear indication state (p7). Hence it is left to the DTE to define DTE to DTE 
protocols able to cope with the various possible situations that may occur. 


4.3.2 User Data Field Length of Data Packets 


The standard maximum user data field length is 128 octets. 


In addition, other maximum user data field lengths may be offered by Administrations 
from the following list: 16, 32, 64, 256, 512, 1024, 2048 and 4096 octets. An optional 
maximum user data field length may be selected for a period of time as the default 
maximum user data field length common to all virtual calls at the DTE/DCE interface 
(see 6.9). A value other than the default may be selected for a period of time for 
each permanent virtual circuit (see 6.9). Negotiation of maximum user data field 
lengths on a per call basis may be made with the flow control parameter negotiation 
facility (see 6.12). 


Procedures for Virtual Circuit Services 39 


IBM Confidential 


| XI permits a default maximum user data field length of between 64 and 1024 octets. 
| For each PVC, a value in the same range can be subscribed to. It may be different 
| from the default value, and different at each end of the PVC. 


The user data field of data packets transmitted by a DTE or DCE may contain any number 
of bits up to the agreed maximum. 


| Note - XI networks require the user data field to contain an integral number of octets. 


If the user data field in a data packet exceeds the locally permitted maximum user 
data field length, then the DCE will reset the virtual call or permanent virtual 
circuit with the resetting cause “Local procedure error™. 


4.3.3 Delivery Confirmation Bit 


The setting of the Delivery Confirmation bit (CD bit) is used to indicate whether or 
not the DTE wishes to receive an end-to-end acknowledgement of delivery, for data it 
15 transmitting, by means of the packet receive sequence number PCR) (see 4.4). 


Note - The use of the D bit procedure does not obviate the need for a higher level | 
protocol agreed between the communicating DTEs which may be used with or without the 
D bit procedure to recover from user or network generated resets and clearings. 


The calling DTE may, during call establishment, ascertain that the D bit procedure 
can be used for the call by setting bit 7 in the General Format Identifier of the call 
request packet to 1 (see 5.1.1). Every network or part of the international network 
will pass this bit transparently. If the remote DTE is able to handle the D bit 


procedure, it should not regard this bit being set to 1 in the incoming call packet 
as invalid. 


Similarly, the called DTE can set bit 7 in the General Format Identifier of the call 
accepted packet to 1. Every network or part of the international network will pass 
this bit transparently. If the calling DTE is able to handle the D bit procedure, 

1t should not regard this bit being set to 1 in the call connected packet as invalid. 


The use by DTEs of the above mechanism in the call request and call accepted packets 
1s recommended but 1s not mandatory for using the D bit procedure during the virtual 
call. 


4.3.% More Data Mark 


If a DTE or DCE wishes to indicate a sequence of more than one packet, it uses a more 
data mark (M bit) as defined below. 


The M bit can be set to 1 in any data packet. When it is set to 1 ina full data packet 
or tn a partially full data packet also carrying the D bit set tol, it indicates that 
more data is to'follow. Recombination with the following data packet may only be 
performed within the network when the M bit is set to 1 in a full data packet which 
also has the D bit set to 0. 


A sequence of data packets with every M bit set to 1 except for the last one will be 
delivered as a sequence of data packets with the M bit set to 1 except for the last 
one when the original packets having the M bit set to 1 are either full Cirrespective 
of the setting of the D bit) or partially full but have the D bit set to 1. 


Two categories of data packets, A and B, have been defined as shown in Table 15/X.25. 
Table 15/X.25 also illustrates the network's treatment of the M and D bits at both 
ends of a virtual call or permanent virtual circuit. 
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TABLE 157X.25 


Definition of two categories of data packets and 
@ network treatment of the M and D bits 


Data packet sent by source Combining with Data packet (a) 
subsequent received by 
packet(s) is destination DTE 
performed by the 
network when 
possible 


Ca) Refers to the delivered data packet whose last bit of user data corresponds to 
the last bit of user data, if any, that was present in the data packet sent 
by the source DTE. 


Note 1 - The originating network will force the M bit to 0. 


@.:- 2 - If the data packet sent by the source DTE 1s combined with other packets, 
up to and including a category B packet, the M and D bit settings in the data packet 
received by the destination DTE will be according to that given in the two right-hand 
columns for the last data packet sent by the source DTE that was part of the 
combination. 


4.3.5 Complete Packet Sequence 


A complete packet sequence is defined as being composed of a single category B packet 
and all contiguous preceding category A packets Cif any). Category A packets have 
the exact maximum user data field length with the M bit set to 1 and D bit set to 0. 
All other data packets are category B packets. 


When transmitted by a source DTE, a complete packet sequence 1s always delivered to 
the destination DTE as a single complete packet sequence. 


Thus, if the receiving end has a larger maximum user data field length than the 
transmitting end, then packets within a complete packet sequence will be combined 
within the network. They will be delivered in a complete packet sequence where each 
packet, except the last one, has the exact maximum user data field length, the M bit 
set to 1, and the D bit set to 0. The user data field of the last packet of the 
sequence may have less than the maximum length and the M and D bits are set as 
described tn Table 15/7X.25. 


If the maximum user data field length is the same at both ends, then user data fields 
of data packets are delivered to the receiving DTE exactly as they have been received 
by the network, except as follows. If a full packet with the M bit set to 1 and D 
bit set to 0 is followed by an empty packet, then the two packets may be merged so 
as to become a single category B full packet. 
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XI does not merge a full packet, with the M bit set to 1 and D bit set to 0 with an 
empty packet, into a single packet when the packet sizes are identical at both ends. 


If the last packet of a complete packet sequence transmitted by the source DTE has a 
data field less than the maximum length, the M bit set to 1 and the D bit set to 0, 

then the last packet of the complete packet sequence delivered to the receiving DTE 

will have the M bit set to 0. 


If the receiving end has a smaller maximum user data field length than the 
transmitting end, the packets will be segmented within the network, and the M and D 
bits will be set by the network as described to maintain complete packet sequences. 


4.3.6 Qualifier Bit 


In some cases, an indicator may be needed with the user data field to distinguish 
between two types of information. It may be necessary to differentiate, for example, 
between user data and control information. An example of such a case is contained 


in Recommendation X.29. 


If such a mechanism 1s needed, an indicator in the data packet header called the 
Qualifier bit (Q bit) may be used. 


The use of the Q@ bit 1s optional. If this mechanism is not needed, the Q bit is always 
set to 0. If the Q bit mechanism is used, the transmitting DTE should set the Q bit 
so as to have the same value (that is, 0 or 1) tin all data packets of the same complete 
packet sequence. A complete packet sequence transferred by the DTE to the DCE in this 
fashion will be delivered to the distant DTE as a complete packet sequence having the 
Q bit set in all packets to the value assigned by the transmitting DTE. 


If the @ bit is not set by the DTE to the same value in all the data packets of a 
complete packet sequence, the value of the Q bit in any of the data packets of the 
corresponding packet sequence transferred to the distant DTE is not guaranteed by the 
network. Moreover, some networks may reset the virtual call or permanent virtual 
circuit as described in Annex C/X.25. 


XI resets the virtual circuit when the Q bit is not set to the same value in a complete 
packet sequence as described in Annex C/X.25. 


Successive data packets are numbered consecutively (see 4.4.1.1) regardless of the 
value of the @ bit. 


4.3.7 Interrupt Procedure 


The interrupt procedure allows a DTE to transmit data to the remote DTE, without 
following the flow control procedure applying to data packets (see 4.4). The 


interrupt procedure can only apply in the flow control ready state (dl) within the 
data transfer state (p4). 


The interrupt procedure has no effect on the transfer and flow control procedures 
applying to the data packets on the virtual call or permanent virtual circuit. 


To transmit an interrupt, a DTE transfers across the DTE/DCE interface a DTE interrupt 
packet. The DTE should not transmit a second DTE_ interrupt packet until the first 
one is confirmed with a DCE interrupt confirmation packet (see Table C-4/X.25). The 
DCE, after the interrupt procedure is completed at the remote end, will confirm the 
receipt of the interrupt by transferring a DCE interrupt confirmation packet. The 
receipt of a DCE interrupt confirmation packet indicates that the interrupt has been 
confirmed by the remote DTE by means of a DTE interrupt confirmation packet. 


The DCE indicates an interrupt from the remote DTE by transferring across the DTE/DCE 


interface a DCE interrupt packet containing the same data field as in the DTE 
interrupt packet transmitted by the remote DTE. A DCE interrupt packet is delivered 
at or before the point in the stream of data packets at which the DTE interrupt packet 
was generated. The DTE will confirm the receipt of the DCE interrupt packet by 
transferring a DTE interrupt confirmation packet. 
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4.3.8 Transit Delay of Data Packets 


Transit delay is an inherent characteristic of a virtual call or a permanent virtual 
circuit, common to the two directions of transmission. 


@::: transit delay is defined as t3c in Recommendation X.135, and is expressed in 


erms of a 95% probability value. 


With XI, the transit delay selection and indication facility is not available. The 
transit delay, as defined in Recommendation X.135, is the responsibility of the 
network service provider, and depends upon the network configuration (mainly the 
maximum number of transit nodes and the speed of inter-node trunks). 


G6.% PROCEDURES FOR FLOW CONTROL 


Paragraph 4.4 only applies to the data transfer state (p4¢) and specifies the 
procedures covering flow control of data packets and reset on each logical channel 
used for a virtual call or a permanent virtual circurt. 


4.4.1 Flow Control 


At the DTE/DCE interface of a logical channel used for a virtual call or permanent 
virtual circuit, the transmission of data packets 1s controlled separately for each 
direction and jis based on authorizations from the receiver. 


On a virtual call or permanent virtual circuit, flow control also allows a DTE to limit 
the rate at which it accepts packets across the DTE/DCE interface, noting that there 
15 a network-dependent limit on the number of data packets which may be in the network 
on the virtual call or permanent virtual circuit. 


4.4.1.1 Numbering of Data Packets 


@:: data packet transmitted at the DTE/DCE interface for each direction of 


ransmission ina virtual call or permanent virtual circuit is sequentially numbered. 


The sequence numbering scheme of the packets is performed modulo 8. The packet 
sequence numbers cycle through the entire range 0 to 7. Some Administrations will 
provide the extended packet sequence numbering facility (see 6.2) which, if selected, 
provides a sequence numbering scheme for packets being performed modulo 128. In this 
case, packet sequence numbers cycle through the entire range 0 to 127. The packet 
sequence numbering scheme, modulo 8 or 128, is the same for both directions of 
transmission and 1s common for all logical channels at the DTE/DCE interface. 


XI supports the extended packet sequence numbering facility (modulo 128) as an 
individual DTE subscription parameter. 


Only data packets contain this sequence number called the packet send sequence number 
P(S). 


The first data packet to be transmitted across the DTE/DCE interface for a given 
direction of data transmission, when the logical channel has just entered the flow 
control ready state (dl), has a packet send sequence number equal to 0. 


4.4.1.2 Windon Description 


At the DTE/DCE interface,» a Window 1s defined for each direction of data transmission 
of a logical channel used for a virtual call or permanent virtual circuit. The window 
is the ordered set of W consecutive packet send sequence numbers of the data packets 
authorized to cross the interface. 


The lowest sequence number in the window is referred to as the lower window edge. 
When a virtual call or permanent virtual circuit at the DTE/DCE interface has just 


entered the flow control ready state (dl), the window related to each direction of 
data transmission has a lower window edge equal to 0. 
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The packet send sequence number of the first data packet not authorized to cross the 
interface is the value of the lower window edge plus W (modulo 8» or 128 when 
extended). 


The standard window size W is 2 for each direction of data transmission at the DTE/DCE 
interface. In addition, other Window sizes may be offered by Administrations. An 
optional window size may be selected for a period of time as the default Window size 
common to all virtual calls at the DTE/DCE interface (see 6.10). <A value other than 
the default may be selected for a period of time for each permanent virtual circuit 
(see 6.10). Negotiation of window sizes ona per call basis may be made with the flow 
control parameter negotiation facility (see 6.12). 


The flow control parameter negotiation facility is supported by XI. 


XI permits a default window size of between 1 and 7 Cif modulo 8) and between 1 and 
15 Cif modulo 128). For each PVC, a value in the same range can be selected and may 
be different from the default value. 


4.4.1.3 Flow Control Principles 


When the sequence number P(S) of the next data packet to be transmitted by the DCE 
1s Within the window, the DCE is authorized to transmit this data packet to the DTE. 
When the sequence number P(S) of the next data packet to be transmitted by the DCE 
is outside the window, the DCE will not transmit a data packet to the DTE. The DTE 
should follow the same procedure. 


When the sequence number P(S) of the data packet received by the DCE is the next in 

sequence and is within the window, the DCE will accept this data packet. <A received 
data packet containing a P(S) that is out of sequence (that is, there is a duplicate 
or a gap in the PCS) numbering), outside the window, or not equal to 0 for the first 
data packet after entering the flow control ready state (dl) is considered by the DCE 
as a local procedure error. The DCE will reset the virtual call or permanent virtual 
circuit Csee 4.4.3). The DTE should follow the same procedure. 


A number (modulo 8, or 128 when extended), referred to as a packet receive sequence 
number PCR), conveys across the DTE/DCE interface information from the receiver for 
the transmission of data packets. When transmitted across the DTE/DCE interface, a 
PCR) becomes the lower window edge. In this way, additional data packets may be 

authorized by the receiver to cross the DTE/DCE interface. 


The packet receive sequence number, P(R), is conveyed in data, receive ready CRR), 
and receive not ready CRNR) packets. 


XI will use RNR packets to convey PCR) updates only when the D bit is used by the 
transmitting DTE. Otherwise, congestion due to the receiving DTE is reported by not 
changing the lower edge of the window. Cases of congestion in the network are reported 
using the Reset procedure (see 4.4.3.2). 


The value of a PCR) received by the DCE must be within the range from the last PCR) 

received by the DCE up to and including the packet send sequence number of the next 

data packet to be transmitted by the DCE. Otherwise, the DCE will consider the receipt 
of this PCR) as a procedure error and will reset the virtual call or permanent virtual 
circuit. The DTE should follow the same procedure. 


The receive sequence number PCR) is less than or equal to the sequence number of the 
next expected data packet and implies that the DTE or DCE transmitting PCR) has 
accepted at least all data packets numbered up to and including P(R)-l. 


4.4.1.4 Delivery confirmation 


When the D bit is set to 0 in a data packet having P(S) = p, the significance of the 
returned PCR) corresponding to that data packet (that is, PCR) 2p +1) isa local 
updating of the window across the packet level interface so that the achievable 
throughput 1s not constrained by the DTE to DTE round trip delay across the 
network(s). | 


When the D bit is set to 0 in a data packet, the returned P(R) corresponding to that 
data packet does not signify that a P(R) has been received from the remote DTE. 


When the D bit is set to 1 in a data packet having PCS) = p, the significance of the 
returned PCR) corresponding to that data packet (that is, PCR) > p +1) is an 
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indication that a PCR) has been received from the remote DTE for all data bits in the 
data packet in which the D bit had originally been set to 1. 


Note 1 - A DTE, on receiving a data packet with the D bit set to 1, should transmit 
the corresponding PC(R) as soon as possible in order to avoid the possibility of 

eadlocks (that is, without waiting for further data packets). A data, RR or RNR 
acket may be used to convey the P(R) (see Note to 4.4.1.6). Likewise, the DCE is 
required to send PC(R) to the DTE as soon as possible from when the PC(R) is received 
from the remote DTE. When the DTE is not currently operating the D bit procedure, 
the receipt of a data packet with the D bit set to 1 may be treated by the DTE as an 
error condition. 


Note Z - If a PCR) for a data packet with the D bit set to 1 is outstanding, local 
eee of the window will be deferred for subsequent data packets with the D bit 
se o 0. 


XI returns immediately an update of the P(R) for all data packets with the D bit set 
a provided no congestion condition exists in the network or at the receiving DTE 
side. 


Note 3 - P(R) values corresponding to the data contained in data packets with the D 
bit set to 1 need not be the same at the DTE/DCE interfaces at each end of a virtual 
call or a permanent virtual circuit. 


Note 4 - If the DTE has sent data packets with the D bit set to 0, the DTE does not 
have to wait for local updating of the window by the DCE before initiating a resetting 
or clearing procedure. 


4.4.1.5 DTE and DCE Receive Ready (RR) Packets 


RR packets are used by the DTE or DCE to indicate that it is ready to receive the W 
data packets within the window starting with PCR), where PCR) is indicated in the RR 
packet. 


4.4.1.6 DTE and DCE Receive Not Ready (RNR) Packets 


NR packets are used by the DTE or DCE to indicate a temporary inability to accept 
dditional data packets for a given virtual call or permanent virtual circuit. <A DTE 
or DCE receiving an RNR packet shall stop transmitting data packets on the indicated 
logical channel, but the window is updated by the PCR) value of the RNR packet. The 
receive not ready situation indicated by the transmission of an RNR packet is cleared 
by the transmission in the same direction of an RR packet or by the tnitiation of a 
reset procedure. 


The transmission of an RR packet after an RNR packet at the packet level is not to 
be taken as a demand for retransmission of packets which have already been 
transmitted. 

Note - The RNR packet may be used to convey across the DTE/DCE interface the PCR) value 
corresponding to a data packet which had the D bit set to 1 in the case that additional 
data packets cannot be accepted. 


This is the only case where XI issues a RNR packet. 
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4.4.2 Throughput Characteristics and Throughput Classes 


The attainable throughput on virtual calls and permanent virtual circuits carried at 
the DTE/DCE interface may vary due to the statistical sharing of transmission and 
switch resources and is constrained by: 


1. The access line characteristics, local window size and traffic 
characteristics of other logical channels at the local DTE/DCE 
interface; 


2. The access line characteristics, local window size and traffic characteristics 
of other logical channels at the remote DTE/DCE 
interface; and 


3. The throughput achievable on the virtual call or permanent virtual 
circuit through the network(s) independent of interface characteristics 
including number of active logical channels. This 
throughput may be dependent on network service characteristics 
such as Window rotation mechanisms and/or optional user facilities 
requested on national/international calls. 


The attainable throughput will also be affected by: 
1. The receiving DTE flow controlling the DCE; 


2. The transmitting DTE not sending data packets which have the maximum data 
field length; 


3. The local DTE/DCE window and/or packet sizes; and 


4. The use of the D bit. 


A throughput class for one direction of transmission is an inherent characteristic 
of the virtual call or permanent virtual circuit related to the amount of resources 
allocated to this virtual call or permanent virtual circuit. This characteristic is 
meaningful when the D bit is set to 0 in data packets. It is a measure of the 
throughput that is not normally exceeded on the virtual call or permanent virtual 
circuit. However, due to the statistical sharing of transmission and switching 
resources, it is not guaranteed that the throughput class can be reached 100% of the 
time. 


Depending on the network and the applicable conditions at the considered moment, the 
effective throughput may exceed the throughput class. 


Note - The definition of throughput class as a grade of service parameter 1s for 
further study. The grade of service might be specified when the D bit jis set to 0 
or over a time period between the completion and initiation of successive D bit 
procedures. 


The throughput class can only be reached if the following conditions are met: 


1. The access data links of both ends of a virtual call or permanent 
virtual circuit are engineered for the throughput class; 


2. The receiving DIE is not flow controlling the DCE such that the 
throughput class is not attainable; 


3. The transmitting DTE is sending data packets which have the maximum data 
field length; and 


4. All data packets transmitted on the virtual call or permanent virtual circuit) 
have the D bit set to 0. 


The throughput class is expressed in bits per second. At a DTE/DCE interface, the 
maximum data field length is specified for a virtual call or permanent virtual 
circuit, and thus the throughput class can be interpreted by the DTE as the number 
of full data packets/second that the DTE does not have a need to exceed. 


In the absence of the default throughput classes assiqnment facility (see 6.11), the 
default throughput classes for both directions of transmission correspond to the user 
class of service of the DTE (see 7.2.2.2) but do not exceed the maximum throughput 
class supported by the network. 


46 XI DTE/DCE Interface Description 


IBM Confidential 


Note - The sum of the throughput classes of all virtual calls and permanent virtual 


circuits supported at a DTE/DCE interface may be greater than the data transmission 
rate of the access line. 


The maximum throughput class supported by an XI network depends upon the network 
onfiguration and is the responsibility of the network service provider. 


I supports Cas a subscription parameter) the default throughput class assignment 
facility. Default throughput classes must be lower than or equal to the user class 
of service of the DTE Caccess link speed). 


XI does not support the throughput class negotiation facility. 


The throughput class of a virtual call will be taken as the lowest value between the 
default throughput class of the calling DTE Cor the DTE access link speed if no default 
throughput class is selected) and the default throughput class of the called DTE (or 
the DTE access link speed if no default throughput class is selected). 


4.4.3 Procedure for Reset 


The reset procedure is used to re-initialize the virtual call or permanent virtual 
circuit and in so doing removes in each direction all data and interrupt packets which 
may be in the network (see 4.5). When a virtual call or permanent virtual circuit 
at the DTE/DCE interface has just been reset, the window related to each direction 
of data transmission has a lower window edge equal to 0, and the numbering of 
subsequent data packets to cross the DTE/DCE interface for each direction of data 
transmission shall start from 0. 


The reset procedure can only apply in the data transfer state (p4) of the DTE/DCE 
interface. In any other state of the DIE/DCE interface, the reset procedure is 
abandoned. For example, when a clearing or restarting procedure is initiated, reset 
request and reset indication packets can be left unconfirmed. 


For flow control, there are three states dl, d2 and d3 within the data transfer state 

(p4). They are flow control ready (dl), DTE reset request (d2), and DCE reset 

indication (€d3) as shown in the state diagram in Figure B-3/X.25. When entering state 

4, the logical channel is placed in state dl. Table C-4/X.25 specifies actions taken 
@: the DCE on the receipt of packets from the DTE. 


4.4.3.1 Reset Request Packet 


The DTE shall indicate a request for reset by transmitting a reset request packet 
specifying the logical channel to be reset. This places the logical channel in the 
DTE reset request state (d2). 


4.4.3.2 Reset Indication Packet 


The DCE will indicate a reset by transmitting to the DTE a reset indication packet 
specifying the logical channel being reset and the reason for the resetting. This 
places the logical channel in the DCE reset indication state (d3). In this state, 
the DCE will ignore data, interrupt, RR and RNR packets. 


4.4.3.3 Reset Collision 


Reset collision occurs when a DTE and a DCE simultaneously transmit a reset request 
packet and a reset indication packet specifying the same logical channel. Under these 
circumstances the DCE will consider that the reset is completed. The DCE will not 
expect a DTE reset confirmation packet and will not transfer a DCE reset confirmation 
packet. This places the logical channel in the flow control ready state (dl). 


4.4.3.4 Reset Confirmation Packets 


When the logical channel is in the DTE reset request state (d2), the DCE will confirm 
reset by transmitting to the DTE a DCE reset confirmation packet. This places the 
logical channel in the flow control ready state (dl). 
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The DCE reset confirmation packet can only be interpreted universally as having local 
significance; however, within some Administrations" networks, reset confirmation may 
have end-to-end significance. In all cases the time spent in the DTE reset request 
state (d2) will not exceed time-limit T22 (see Annex D). 


XI offers a local significance to the DCE reset confirmation, in that the DCE reset 
confirmation packet is sent back to the DTE immediately after reception by the DCE 
of a DTE reset request, while the reset procedure is forwarded to the remote DTE. 
This is done in compliance with the requirements of 4.5. 


When the logical channel is in the DCE reset indication state (€d3), the DTE will 
confirm reset by transmitting to the DCE or a DIE reset confirmation packet. This 
places the logical channel in the flow control ready state (dl). The action taken 
by the DCE when the DTE does not confirm the reset within time-out T12 1s given in 
Annex D. 


4.5 EFFECTS OF CLEAR, RESET AND RESTART PROCEDURES ON THE TRANSFER OF PACKETS 


All data and interrupt packets generated by a DTE (Cor the network) before initiation 
by the DTE or the DCE of a clear, reset or restart procedure at the local interface 
will either be delivered to the remote DTE before the DCE transmits the corresponding 
indication on the remote interface, or be discarded by the network. 


No data or interrupt packets generated by a DTE (or the network) after the completion 
of a reset Cor for permanent virtual circuits also a restart) procedure at the local 
interface will be delivered to the remote DTE before the completion of the 
corresponding reset procedure at the remote interface. 


When a DTE initiates a clear, reset or restart procedure at its local interface, all 
data and interrupt packets which were generated by the remote DTE Cor the network) 
before the corresponding indication is transmitted to the remote DTE will be either 
delivered to the initiating DTE before DCE confirmation of the initial clear, reset 
or restart request, or be discarded by the network. 


Data packets waiting in an XI node for transmission on a DTE access line or ona line 
to another node are discarded when the restart, clear, or reset procedure is initiated 
in that node. 


Note - The maximum number of packets which may be discarded is a function of network 
end-to-end delay and throughput characteristics and, in general, has no relation to 
the local window size. For virtual calls and permanent virtual circuits on which all 
data packets are transferred with the D bit set to 1, the maximum number of packets 
which may be discarded in one direction of transmission is not larger than the window 
size of the direction of transmission. 


4.6 EFFECTS OF PHYSICAL AND LINK LEVEL FAILURES 
When a failure at the physical and/or link level is detected, the DCE will transmit 
to the remote end: 
1. A reset with the cause "Out of order” for each permanent virtual circuit; and 
2. A clear with the cause "Out of order™ for each existing virtual call. 
During the failure: 
1. The DCE will clear any incoming virtual call with the cause "Out of order"; 
2. For any data or interrupt packet received from the remote DTE on a permanent 
virtual circuit, the DCE will reset the permanent virtual circuit with 
the cause "Out of order"; 
3. A reset packet received from the remote DTE on a permanent virtual circuit 


will be confirmed to the remote DTE by either reset confirmation or 
reset indication packet 
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When the failure is recovered on the physical and link levels, the restart procedure 
will be actioned (see 3.5) and a reset with the cause "Remote DTE operational” will 
be transmitted to the remote end of each permanent virtual circuit. 
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5. PACKET FORMATS 


5.1 GENERAL 


The possible extension of packet formats by the addition of new fields is for further 
study. 


Note - Any such field: 


1. Would only be provided as an addition following all previously defined fields, 
and not as an insertion between any of the previously defined fields 


2. Would be transmitted to a DTE only when either the DCE has been informed 
that the DTE is able to interpret this field and act upon it, or when 
the DTE can ignore the field without adversely affecting the operation 
of the DTE/DCE interface Cincluding charging) 


3. Would not contain any information pertaining to a user facility to which 
the DTE has not subscribed, unless the DTE can ignore the facility 
without adversely affecting the operation of the DTE/DCE interface 
Cincluding charging). 


Bits of an octet are numbered 8 to 1 where bit 1 is the low order bit and is 
transmitted first. Octets of a packet are consecutively numbered starting from 1 and 
are transmitted in this order. 


5.1.1 General Format Identifier 


The general format identifier field is a four bit binary coded field which is provided 
to indicate the general format of the rest of the header. The general format 
identifier field is located in bit positions 8, 7, 6 and 5 of octet 1, and bit 5 is 
the low order bit (see Table 16/X.25). 


Bit 8 of the general format identifier 1s used for the Qualifier bit in data packets 
and is set to 0 tin all other packets. 


Bit 7 of the general format identifier is used for the delivery confirmation procedure 
in data and call set-up packets and 1s set to 0 tin all other packets. 


Bits 6 and 5 are encoded for four possible indications. Two of the codes are used 
to distinguish packets using modulo 8 sequence numbering from packets using modulo 
128 sequence numbering. The third code is used to indicate an extension to an expanded 
format for a family of general format identifier codes which are a subject of further 
study. The fourth code is reserved for other applications. 


Note 1 - The DTE must encode the GFI to be consistent with whether or not it has 
subscribed to the extended packet sequence numbering facility (see 6.2). 


Note 2 - It is envisaged that other general format identifier codes could identify 
alternative packet formats. 


50 XI DTE/DCE Interface Description 


IBM Confidential 


TABLE 16/7X.25 


General format identifier 


identifier 


Sequence numbering scheme modulo 8 0x01 
Sequence numbering scheme modulo 128 0 xX 1 0 


Sequence numbering scheme modulo 8 ee 
registration, and Sequence numbering scheme modulo 128 001 0 
diagnostic packets 


[Genarei format identifier extension SC* 
[Reserved for other applications ———SSSSCSC*id 


*¥ Undefined. 


General format 


Call set-up packets 


Clearing, flow 
control, interrupt, 
reset, restart, 


Note - A bit which is indicated as "X" may be set to either 0 or 1 as indicated in 
the text. 


5.1.2 Logical Channel Group Number 


@. logical channel group number appears in every packet except restart, diagnostic, 
and registration packets in bit positions 4, 3, 2 and 1 of octet 1. For each logical 
channel, this number has local significance at the DTE/DCE interface. 


This field is binary coded and bit 1 is the low order bit of the logical channel group 
number. In restart, diagnostic and registration packets, this field 1s coded all 
zeros. 


5.1.3. Logical Channel Number 


The logical channel number appears in every packet except restart, diagnostic, and 
registration packets in all bit positions of octet 2. For each logical channel, this 
number has local significance at the DTE/DCE interface. 


This field is binary coded and bit 1 is the low order bit of the logical channel 


number. In restart, diagnostic and registration packets, this field is coded all 
zeros. | 


5.1.4 Packet Type Identifier 


Each packet shall be identified in octet 3 of the packet according to Table 17/X.25. 


With XI, the packet retransmission additional facility is not available, thus the DTE 
REJ packet 1s not handled. 


Also the online registration facility is not available, thus registration request and 
_— confirmation packets are not handled. 


Packet Formats 51 


IBM Confidential 


| In both cases, when such packets are sent by the DCE, the DCE reacts as indicated in 
| Annex C Crestart, clear, or reset sent to the DTE). 


TABLE 177X.25 @ 


Packet Type Identifier 


Packet type 


From DCE to DTE From DTE to DCE 
CALL SET-UP AND CLEARING 


Incoming call Call request 

Call connected Call accepted 

Clear indication Clear request 

DCE clear confirmation DTE clear confirmation 


DATA AND INTERRUPT 


data DTE data 
interrupt DTE tnterrupt 
interrupt confirmation DTE interrupt confirmation 


FLOW CONTROL AND RESET 


RR (modulo 8) DTE RR Cmodulo 8) 
RR (modulo 128)(Ca) DTE RR Cmodulo 128)(Ca) 
RNR (modulo 8) DTE RNR (modulo 8) 
DCE RNR (modulo 128)(a) DTE RNR (modulo 128)Ca) 
DTE REJ (modulo 8)(a) 
DTE REJ (modulo 128)(Ca) 
Reset indication Reset request 
DCE reset confirmation DTE reset confirmation 


RESTART 


Restart indication Restart request 1 _ 
DCE restart confirmation DTE restart confirmation 


e2o0oxKoxKoOXK 
e200xoxox 
C200xoaxox< 
Re OaaQaocoo 
mimi OOOO 
HMOOOKrF OO 
mHmmMOooaaooo 
fmO fad fad fed feud feed fd feed 


DIAGNOSTIC 
Diagnostic(a) 
REGISTRATION(Ca) 


Registration request 


Registration confirmation 


Ca) Not necessarily available on all networks. 


Note - A bit which is indicated as "X" may be set to either 0 or 1 as indicated in 
the text. 
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5.2 CALL SET-UP AND CLEARING PACKETS 


5.2.1 Call Request and Incoming Call Packets 


>. 2/X.25 illustrates the format of call request and incoming call packets. 


Bits 
8 7 6 5 4 3 2 1 


General format identifier 
1 (see Note 1) 


0 2 
Cc 
t 
: Packet type identifier 
S 0 0 1 
4 
: DTE address(es) $ 


: (see Note 2) 


Facility length 


& : Facilities : 


Call user data : 


Note 1 - Coded 0X01 (modulo 8) or OX10 Cmodulo 128). 


Note 2 - The figure is drawn assuming the total number of address digits present is 
odd. 


FIGURE 2/7X.25 


Call request and incoming call packet format 


5.2.1.1 General Format Identifier 


Bit 7 of octet 1 should be set to 0 unless the mechanism defined in 4.3.3 is used. 


5.2.1.2 Address Lensth Fields 


Octet 4 consists of field Length tndicators for the called and calling DTE addresses. 
Bits 4, 3, 2, and 1 indicate the length of the called DTE address in semi-octets. 
Bits 8, 7, 6 and 5 indicate the length of the calling DTE address in semi-octets. 
Each address length indicator is binary coded and bit 1 or 5 is the low order bit of 
the indicator. 
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5.2.1.3 address Field 


Octet 5 and the following octets consist of the called DTE address when present, then 
the calling DTE address when present. 


Each digit of an address is coded in a semi-octet in binary coded decimal with bit 5 
or 1 being the low order bit of the digit. 


Starting from the high order digit, the address 1s coded in octet 5 and consecutive 
octets with two digits per octet. In each octet, the higher order digit is coded in 
bits 8> I 6 and 5. 


The address field shall be rounded up to an integral number of octets by inserting 
zeros tn bits 4, 3, 2 and 1 of the last octet of the field when necessary. 


Note - This field may be used for optional addressing facilities such as abbreviated 
addressing. The optional addressing facilities employed as well as the coding of 
those facilities are for further study. 


The format of XI DTE addresses in an XI environment is described in 5.8. 


5.2.1.% Facility Length Field 


The octet following the address field indicates the length of the facility field in 


octets. The facility length indicator is binary coded and bit 1 is the low order bit 
of the tndicator. 


5.2.1.5 Factlity Field 


The facility field is present only when the DTE is using an optional user facility 
requiring some indication in the call request and incoming call packets. 


The coding of the facility field is defined in 6 and 7. 


The facility field contains an integral number of octets. The actual maximum length 
of this field depends on the facilities which are offered by the network. However, 
this maximum does not exceed 109 octets. 


5.2.1.6 Call User Data Field 


Following the facility field, the call user data field may be present and has a maximum 
length of 128 octets when used itn conjunction with the fast select facility described 
in 6.16, 16 octets in the other case. 


Note - XI networks require the call user data field to contain an integral number of 
octets. 


When the virtual call is being established between two packet-mode DTEs, the network 
does not act on any part of the call user data field. See Recommendation X.244. 
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5.c.c¢ Call Accepted and Call Connected Packets 


Figure 3/X.25 illustrates the format of call accepted and call connected packets in 
the basic or extended format. 


Bits 


General format identifier 
1 (see Note 1) 


0.6 2 
Cc 
t 
e 
t 3 
S 
4 
: DTE address(es) : 
: (see Note 2) : 
5 
Ca) 
Facility length 
Facilities : 
: . : 
@ : Called user data(lb) : 


(a) These fields are not mandatory in the basic format of call accepted packets 
(see 5.2.2.1). 


(b)} This field may be present only in the extended format (see 5.2.2.2). 
Note 1 - Coded 0X01 (modulo 8) or 0X10 (modulo 128). 


Note 2 - The figure 1s drawn assuming the total number of address digits present is 
odd. 


FIGURE 3/7X.25 


Call accepted and call connected packet format 
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5.2.2.1 Basic Format 
5.2.2.1.1 General Format Identifier 


Bit 7 of octet 1 should be set to 0 unless the mechanism defined in 4.3.3 is used. 


5.2.2.1.2 Address Length Fields 


Octet 4 consists of field length indicators for the called and calling DTE addresses. 
Bits 4, 3, 2 and 1 indicate the length of the called DTE address in semi-octets. Bits 
8, 7, 6 and 5 indicate the length of the calling DTE address in semi-octets. Each 
address length indicator is binary coded and bit 1 or 5 is the low order bit of the 
indicator. 


The use of the address length fields in call accepted packets is only mandatory when 
the address field or the facility length field is present. 


5§.2.2.1.3 Address Field 
Octet 5 and the following octets consist of the called DTE address when present, then 
the calling DTE address when present. 


Each digit of an address is coded in a semi-octet itn binary coded decimal with bit 5 
or 1 being the low order bit of the digit. 


Starting from the high order digit, the address its coded in octet 5 and consecutive 
octets with two digits per octet. In each octet, the higher order digit is coded in 
bits 8, 7, 6 and 5. 


The address field shall be rounded up to an integral number of octets by inserting 
zeros in bits 4, 3, 2 and 1 of the last octet of the field when necessary. 


Note - This field may be used for optional addressing facilities such as abbreviated 
addressing. The optional addressing facilities employed as well as the coding of 
those facilities is for further study. 

The format of XI DTE addresses in an XI environment is given at the end of 5.8. 
5.2.2.1.4 Facility Length Field 

The octet following the address field indicates the length of the facility field in 
octets. The facility length indicator 1s binary coded and bit 1 is the low order bit 


of the tndicator. 


The use of the facility length field in call accepted packets 1s only mandatory when 
the facility field is present. 


5.2.2.1.5 Facility Field 


The facility field is present only when the DTE is using an optional user facility 
requiring some indication in the call accepted and call connected packets. 

The coding of the facility field is defined in 6 and 7. 

The facility field contains an integral number of octets. The actual maximum length 
of this field depends on the facilities which are offered by the network. However, 
this maximum does not exceed 109 octets. 


5.2.2.2 Extended Format 


The extended format is not supported by XI, because XI does not support the fast select 
facility which would require the use of the extended format. 
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5.2.3 Clear Request and Clear Indication Packets 


Figure 4/7X.25 illustrates the format of clear request and clear indication packets, 
in basic and extended formats. 


Bits 


General format identifier 
1 (see Note 1) 


0 2 
c 
t 
e 
t 3 
S 
4 Clearing cause 
5 Diagnostic codeCla) 
6 Calling DTE address length Called DTE address length 
DTE address(es) 
(see Note 2) 
7 
& Facility length Cb) 
Facilities : 
: : 
- Clear user data : 


Ba ee es ee 

Ca) This field 1s not mandatory itn the basic format of clear request packets. 
Cb) Used only in the extended format (see 5.2.3.2). 

Note 1 ~ Coded 0001 (modulo 8) or 0010 (modulo 128). 


Note 2 - The figure is drawn assuming the total number of address digits present is 
odd. 


FIGURE 47X.25 


Clear request and clear indication packet format 
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5.2.3-1 Basic Format 


5.2.3.1.1 Clearing Cause Field 


Octet 4 is the clearing cause field and contains the reason for the clearing of the 
call. 


In clear request packets, the clearing cause field should be set by the DTE to one 
of the following values: 


bits :8 76564321 
value : 00000090 0 
or > 1X XXXKXK XK X 


where each X may be independently set to 0 or 1 by the DTE. 


See the note below Table 18/X.25 for the values allowed for a DTE attached to an XI 
node. 


The DCE will prevent values of the clearing cause field other than those shown above 
from reaching the other end of the call by either accepting the clear request packet 
and forcing the clearing cause field to all zeros in the corresponding clear 
indication packet, or considering the clear request as an error and following the 
procedure described in Annex C. 


XI considers a "not-permitted”™ cause field issued by a DTE as an error and will take 
the actions described in Annex C. 


The coding of the clearing cause field in clear indication packets is given in Table 
18/X.25. 


TABLE 18/7X.25 


Coding of Clearing Cause Field in Clear Indication Packet 


Co 
wo 
cr 
ul 


b=? ft f= eooe aaoooooe xO A 


DTE originated 
DTE originated(a) 


Number busy 
Out of order 
Remote procedure error 

Reverse charging acceptance not subscribed(b) 
Incompatible destination 

Fast select acceptance not subscribed(b) 

Ship absent(c) 


: 


ore oS Ore & me OF OF © xO & 


Invalid facility request 
Access barred 
Local procedure error 


Network congestion 
Not obtainable | 
RPOA out of order(b) 


ooo ooo ooooo0nco xO ~J 
ooo [200 Meme Ooooo xO fo.) 
Hoo mH OO MOoOOrHF OO xO yi 
ooo fat fund fad Qo0o0o00o0o xO ne] 
fond fad fund fond fad fend fad fant fed fund fmt feed fed <OQ fen 


ooo ooo aeo0aoocooas 


a. When bit 8 is set to 1, the bits represented by Xs are those included by the 
remote DTE in the clearing or restarting cause field of the clear or restart 
request packet respectively. 

Table 18.17X.25 gives the different clearing cause values accepted or 
generated by XI, or generated by DTEs in restart request packets, and 
delivered on SVCs. 


b. May be received only if the corresponding optional user facility is used. 


c. Used in conjunction with mobile maritime services. 
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| The cause codes generated by a DCE in an XI node are controlled by a cause qualifier 
| parameter. This parameter is chosen by the network provider to be either 'standard' 


j or 


* 


"specific': 


When the cause qualifier parameter value is "standard", and the DTE has subscribed 
to the 1984 version of X.25, the values of the cause field for a DTE are those 
in Table 18/X.25. The values which may be sent to DTEs attached to the XI network 
are those in Table 18/X.25, irrespective of the origin of the clear (the XI 
network or a PSDN connected through a GW-DTE function). 


However, when clears are passed to a PSDN through the GNW-DTE function, bit 8 of 
the cause field is set to 1 so as to comply with the Recommendation, irrespective 
of the origin of the clear (the DTE on the XI network or the XI network itself), 
provided the PSDN accepts it (see Table 18.1/X.25). 


When the cause qualifier parameter value is "specific", the values generated by 
the XI network are those in Table 18/X.25 with bit 8 set to 1. Clears issued by 
a PSDN are those in Table 18/X.25, and thus can be differentiated from clears 
issued by the XI network. A DTE attached to the PSDN will also be capable of 
differentiating the network origin of the clear. 


Table 18.1/7X.25 summarizes XI handling for various combinations of DTEs, GW-DTE, and 
XI parameters. 


Notes: 


vvvvvvv is bits 7 to 1 of any cause code explicitly shown in Table 18/X.25 
Nnnnnnnn is any bit value other than vvvvvvv. 


DTE 80 is a DTE attached to the XI network with parameter "™X.25 1980" 
DTE 84 is a DTE attached to the XI network with parameter "X.25 1984" 


GW 80 is a GW-DTE towards a PSDN based on the 1980 version of X.25 
GW 84 is a GW-DTE towards a PSDN based on the 1984 version of X.25. 
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TABLE 18.17X.25 (part 1 of 2) 


XI Handling of Clearing Causes 


CAUSE QUALIFIER = STANDARD 
Source 
DTE 80 DIE 84 | GW 80 | GW 84 


DTE 80} 00000000 00000000 00000000 00000000 00000000 
C1) 

DTE 84} 00000000 00000000 00000000 00000000 00000000 
(2) 10000000 00000000 10000000 00000000 10000000 
GW 80 00000000 00000000 00000000 
C3) Ovvvvvvv Ovvvvvvyv Ovvvvvvv 
GW 84 00000000 00000000 00000000 
Ovvvvvvv Ovvvvvevyv OvvuvvvvyY 
lvvvvvvv Ovyvvvvvy lyvvvvvv 
Innnnnonn Onnnnnnn Innnnnnn 


€1) In principle, DTEsS complying with the 1980 version of X.25 should not issue causes 
with first bit (bit 8) set to 1. This is not checked by XI. 


Not applicable 


(2) For compliance with ISO standard 8208. 


(3) GW defined as X.25 1980 compatible should not transit cause values with bit 8 set 
to 1. This is not checked by XI ‘ 


TABLE 18.17X.25 (part 2 of 2) 


XI Handling of Clearing Causes 


CAUSE QUALIFIER = SPECIFIC 


Destination 


Source 
DTE 80 DTE 8&4 | GW 80 | GW 84. 


DTE 80; 00000000 00000000 00000000 00000000 00000000 
(1) 

DTE 84} 00000000 00000000 00000000 00000000 00000000 
(2) 10000000 00000000 10000000 00000000 10000000 


GW 80 00000000 00000000 00000000 
C3) Ovvvvvvy Ovvvvvvy OvvvvvvyY 


GW 84 00000000 00000000 00000000 
Ovvvvvvy Ovvvyvvvy Ovvvvvvyv 
lyvvvvvvv Ovvvvvvy lyvvvvvv 
lnnnnnnn Onnnnnnn Innnnnnn 


C1), €2), €3) Same as above. 


Not applicable 


60 XI DTE/DCE Interface Description 


IBM Confidential 


5.2.3.1.2 Diagnostic Code 


Octet 5 is the diagnostic code and contains additional information on the reason for 
the clearing of the call. 


@. a clear request packet, the diagnostic code is not mandatory. 


In a clear _ indication packet, if the clearing cause field indicates "DTE originated", 
the diagnostic code is passed unchanged from the clearing DTE. If the clearing DTE 
has not provided a diagnostic code in its clear request packet, then the bits of the 
diagnostic code in the resulting clear indication packet will all be zero. 


When a clear indication packet results from a restart request packet, the value of 
the diagnostic code will be that specified in the restart request packet, or all zeros 
in the case where no diagnostic code has been specified in the restart request packet. 


When the clearing cause field does not indicate "DTE originated”, the diagnostic code 
in a clear indication packet is network generated. Annex E lists the codings for 
network generated diagnostics. The bits of the diagnostic code are all set to 0 when 
no specific additional information for the clearing 1s supplied. 


Note ~- The contents of the diagnostic code field do not alter the meaning of the cause 
field. A DTE is not required to undertake any action on the contents of the diagnostic 
code field. Unspecified code combinations in the diagnostic code field shall not 
cause the DTE to refuse the cause field. 


5.2.3.2 Extended Format 


The extended format is used for clear request and clear indication packets only when 
the DTE or the DCE needs to use the address field, the facility field and/or the clear 
user data field in conjunction with one or several optional user facilities described 
in ss. 6 and 7. The address field is used only when the called line address modified 
notification facility is used in clearing, tin response to an incoming call or call 
request packet. 


When the extended format is used, the diagnostic code field, the address length fields 
and the facility length field must be present. Optionally, the clear user data field 


ay also be present. 
qe. extended format can be used by the DTE, with the call transfer selection facility 


included, to transfer a virtual call to another DTE. If the call transfer selection 
facility 1s not present, the clearing procedure 1s completed as with the basic format. 


5.2.3.2.1 Address Length Fields 


Octet 6 consists of field length indicators for the called and calling DTE addresses. 
Bits 4, 3, 2 and 1 indicate the length of the called DTE address in semi-octets. Bits 
8, 7, 6 and 5 indicate the length of the calling DTE address in semi-octets. Each 
address length indicator is binary coded and bit 1 or 5 is the low order bit of the 
indicator. 


5.2.3.2.2 Address Field 
When present, octet 7 and the following octets consist of the called DTE address when 
present, then the calling DTE address when present. 


Each digit of an address is coded in a semi-octet in binary coded decimal with bit 5 
or 1 being the low order bit of the digit. 


Starting from the high order digit, the address is coded in octet 7 and consecutive 
octets with two digits per octet. In each octet, the higher order digit is coded in 
bits 8, 7, 6 and 5. 


The address field shall be rounded up to an integral number of octets by inserting 
zeros in bits 4, 3, 2 and 1 of the last octet of the field when necessary. 
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5.2.3.2.3 Facility Length Field 


The octet following the address field indicates the length of the facility field in 
octets. The facility length indicator is binary coded and bit 1 is the low order bit 
of the indicator. 


5.2.3.2.4 Facility Field 


The facility field is present in the clear request or the clear indication packet only 
in conjunction with one or several optional user facilities requiring some indication 
in this packet. 


The coding of the facility field is defined in ss. 6 and 7. 


The facility field contains an integral number of octets. The actual maximum length 
of this field depends on the facilities which are offered by the network. However, 
this maximum does not exceed 109 octets. 


If the call transfer selection facility its present, then the virtual call is 
transferred to the address included in the facility Calternate DTE address). 
CCITT-defined facilities included by the clearing DTE are transferred to the alternate 
DTE. Non X.25 facilities in the network of the alternate DTE are also transferred. 
Both types of facilities are delivered to the alternate DTE in the Facility Field of 
the incoming call packet resulting from the transfer. XI does not accept other X.25 
facilities in the clear request packet tn extended format. If any are present, the 
virtual call is simply cleared, and no transfer occur. 


If the call transfer selection facility is not present, all other facilities are 
Ignored. 


5.2.3.2.5 Clear User Data Field 


This field may be present. If present, it is limited to 16 octets, and must contain 
an integral number of octets. 


If the call transfer selection facility is present, then the Clear User Data Field 


is transferred to the alternate DTE, in the incoming call packet resulting from the 
transfer. 


If the call transfer selection is not present, the clear request packet is rejected 
by a clear indication packet, with a cause "Local procedure error” and a diagnostic 
"Packet too long". 


When a virtual call has been established or is being cleared between two packets mode 
DTEs, the network does not act on any part of the clear user data field. See 
Recommendation X.244. 


5.2.4 DTE and DCE Clear Confirmation Packets 


Figure 5/7X.25 illustrates the format of the DTE and DCE clear confirmation packets, 
in the basic or extended format. 


The extended format may be used for DCE clear confirmation packets only in conjunction 
with the charging information facility described in 6.22. It is not used for DTE clear 


confirmation packet. 
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Bits 


General format identifier 
(see Note) Logical channel group number 


2 Logical channel number 


Packet type identifier 
0 1 0 


Ue tO O & 
j—_ 


G Calling DTE address length Called DTE address length 


5 : DTE address(Cles) : 


Ca) 


Facility length 


Facilities 


e 
e 


Se ee a a ae a EE RS RO NE 


(a) Used only in the extended format of DCE clear confirmation packets. 


Note - Coded 0001 (modulo 8) or 0010 (modulo 128). 


FIGURE 5/7X.25 


© DTE_and DCE clear confirmation packet format 


| XI does not include the charging information facility, thus the extended format for 
|} the DCE clear confirmation packet is not used: X.25 5.2.4.1 to 5.2.4.4 are therefore 
| not applicable in the XI environment. 


5.3 DATA AND INTERRUPT PACKETS 


5.3.1 DTE and DCE Data Packets 


Figure 6/X.25 illustrates the format of the DTE and DCE data packets. 
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Nieto tao 


Bits 
8 7 6 5 4 3 2 1 
General format identifier 

1 

2 

3 

: User data : 
(Modulo 8) 
Bits 
8 7 6 5 4 3 2 1 
General format identifier 
1 
Q D 

0 2 
c 
t 
e 
t 3 
S 

4 


User data : 


(When extended to modulo 128) 
D Delivery confirmation bit 
M More data bit 
Q Qualifier bit 
FIGURE 6/X.25 


DTE and DCE Data Packet Format 


5.3.1.1 Qualifier (Q) Bit 
Bit 8 of octet 1 is the qualifier (Q) bit. 


5.3.1.2 Delivery Confirmation (D) Bit 

Bit 7 of octet 1 is the delivery confirmation (CD) bit. 

5.3.1.3 Packet Receive Sequence Number 

Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended, are used 


to indicate the packet receive sequence number PCR). PCR) is binary coded and bit 
6, or bit 2 when extended, is the low order bit. 
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5.3.1.4 More Data Bit 


Bit 5 in octet 3, or bit 1 in octet 4 when extended, is used for the more data mark 
(M bit): 0 for no more data and 1 for more data. 


@.;.1.5 Packet Send Sequence Number 


Bits 4, 3 and 2 of octet 3, or bits 8 through 2 of octet 3 when extended, are used 


to indicate the packet send sequence number P(S). PCS) is binary coded and bit 2 is 
the low order bit. 


5.3.1.6 User Data Field 
Bits following octet 3, or octet 4 when extended, contain user data. 
| Note: XI networks require the user data field to contain an integral number of octets. 


5.3.2 DTE and DCE Interrupt Packets 


Figure 7/X.25 illustrates the format of the DTE and DCE interrupt packets. 


Bits 
8 7 6 5 4 3 2 1 


General format identifier 
1 (see Note) 


0 2 
Cc 
t 
@ Packet type identifier 
3 
S 1 0 0 
G 3 Interrupt user data : 


Note ~- Coded 0001 (modulo 8) or 0010 (modulo 128). 


FIGURE 77X.25 


DTE and DCE Interrupt Packet Format 


5.3.2.1 Interrupt User Data Field 


Octet 4 and any following octets contain the interrupt user data. This field may 
contain from 1 to 32 octets. 


| Note - XI networks require the interrupt user data field to contain an integral number 
| of octets. 


5.3.3 DTE and DCE Interrupt Confirmation Packets 


Figure 8/X.25 illustrates the format of the DTE and DCE interrupt confirmation 
packets. 
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Bits 


General format identifier 


1 (see Note) 
0 
Cc 
t 
e 2 
t 
S 
3 


Note - Coded 0001 (modulo 8) or 0010 (modulo 128). 


FIGURE 8/X.25 


DTE and DCE interrupt confirmation packet format 
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5.4% FLOW CONTROL AND RESET PACKETS 


5.4.1 DTE and DCE Receive Ready (RR) Packets 


e... 9/X.25 illustrates the format of the DIE and DCE RR packets. 


Bits 


General format identifier 


1 
0 0 0 
0 
e -2 
t 
e 
t Packet type identifier 
s 3 
0 0 
(Modulo 8) 
General format identifier 
1 Logical channel group number 


0 0 1 


Logical channel number 


Packet type identifier 


np A 
N 


(When extended to modulo 128) 


FIGURE 97X.25 
DTE and DCE RR Packet Format 


5.4.1.1 Packet Receive Sequence Number 
Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended, are used 


to indicate the packet receive sequence number PCR). PCR) is binary and bit 6, or 
bit 2 when extended, ts the low order bit. 


5.4.2 DTE and DCE Receive Not Ready (RNR) Packets 


Figure 10/X.25 illustrates the format of the DTE and DCE RNR packets. 
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Bits 


General format identifier 


0.6(U61 
Cc 0 0 0 
t 
e 
t 2 Logical channel number 
S 
Packet type identifier 
3 
0 1 0 
(Modulo 8) 
Bits 
8 7 6 5 4 3 2 1 
' General format identifier 
0 0 1 

0 2 
c 
t 
e 
t 3 
S 

4 


(When extended to modulo 128) 


FIGURE 107X.25 
DTE and DCE RNR Packet Format 


5.4.2.1 Packet Receive Sequence Number 


Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended, are used 
to indicate the packet receive sequence number PCR). PCR) is binary coded and bit 
6, or bit 2 when extended, is the low order bit. 


5.4.3 Reset Request and Reset Indication Packets 


Figure 11/7X.25 illustrates the format of the reset request and reset indication 
packets. 
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Bits 


General format identifier 
(see Note) 


Tao ie oO) @ 
fae 


4 Resetting cause 


5 Diagnostic code(a) 


Ca) This field is not mandatory in reset request packets. 


Note: Coded 0001 (modulo 8) or 0010 (modulo 128). 


FIGURE 11/7X.25 


Reset Request and Reset Indication Packet Format 


5.4.3.1 Resetting Cause Field 
e* 4 is the resetting cause field and contains the reason for the reset. 


n reset request packets, the resetting cause field should be set by the DTE to one 
of the following values: 


bits : 87654321 
value : 0000000 0 
or : 1X XXX*KxXKXXKX 
where each X may be independently set to 0 or 1 by the DTE 


See the note below Table 19/X.25 for the values permitted to a DTE attached to an XI 
node. 


The DCE will prevent values of the resetting cause field other than those shown above 
from reaching the other end of the virtual call or permanent virtual circuit by either 
accepting the reset request packet and forcing the resetting cause field to all zeros 
in the corresponding reset indication packet, or considering the reset request as an 
error and following the procedure described in Annex C. 


XI considers a not-permitted cause field issued by a DTE as an error and will take 
the actions described in Annex C. 


The coding of the resetting cause field in a reset indication packet 1s given in Table 
19/7X.25. 
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TABLE 197X.25 


Coding of Resetting Cause Field tin Reset Indication Packet 


oo 
es) 
ct 
ui 


HKHOKMmMOaDQO0! xa! 


DTE originated 
DTE originated(a) 


Out of order(b) 

Remote procedure error 
Local procedure error 
Network congestion 

Remote DTE operational(b) 
Network operational (Cb) 
Incompatible destination 
Network out of order(b) 


: 


OQqQ0q0CcCocCoOO0oO 

Eamr2o0ceca0a0da0 |! <a ln 
E2g0qaaqng0cQg0 [| xKXa}]a 
KE QaQanmneaaqoo \| Ka; uw 
RFORP OF ROO] KO] Ww 
SOOrFOrFOrFO | «KO !] M 
ft ft et fe pe Oe | KO OC 


a. When bit 8 is set to 1, the bits represented by Xs are those indicated by the 
remote DTE in the resetting cause field (virtual calls and permanent virtual 
circuits) or the restarting cause field (permanent virtual circuits only) of 
the reset or restart request packet respectively. 

Table 19.1/X.25 describes the different resetting cause values accepted or 
generated by XI, or generated by DTEs, itn restart request packets, and 
delivered on PVCs. 


b. Applicable to permanent virtual circuits only. 


The cause codes generated by a DCE in an XI node are controlled by a cause qualifier 
parameter. This parameter is chosen by the network provider to be either 'standard' 


or 


*specific'’: 


When the cause qualifier parameter value is "standard”, and the DTE has subscribed 
to the 1984 version of X.25, the values of the cause field sent for a DTE should 
be selected from Table 19/X.25. The values which may be sent to DTEs attached 
to the XI network are those in Table 19/X.25, irrespective of the origin of the 
reset (the XI network or a PSDN connected through a GW-DTE function). 


However, when resets are passed to a PSDN through the GW-DTE function, the bit 8 
of the cause 1s set to 1 so as to comply with the Recommendation, irrespective 
of the origin of the reset (the DTE on the XI network or the XI network itself), 
provided the PSDN accepts it (see Table 19.1/X.25). 


When the cause qualifier parameter value is “specific”, the values generated by 
the XI network are those shown in Table 197X.25 with bit 8 set to 1. Reset codes 
issued by a PSDN are those shown in Table 19/X.25, and can thus be differentiated 
from resets issued by the XI network. A DTE attached to the PSDN will also be 
capable of differentiating the network origin of the reset. 


Table 19.1/X.25 summarizes XI handling for various combinations of DTEs, GW-DTE and 
XI parameters: 


Notes: 
vyvvvvv is bits 7 to 1 of any cause code explicitly shown in Table 197X.25 
Nnnnnnn is any bit value other than vyvvvvvv 
DTE 80 is a DTE attached to the XI network with parameter "X.25 1980" 
DTE 84 is a DTE attached to the XI network with parameter "™X.25 1984" 
GW 80 is a GNW-DTE towards a PSDN based on the 1980 version of X.25 
GW 84 is a GWN-DTE towards a PSDN based on the 1984 version of X.25. 
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TABLE 19.17X.25 (Cpart 1 of 2) 


XI_ handling of resetting causes 


CAUSE QUALIFIER = STANDARD 


Destination 


Saeed | iestination 
DTE 80 DTE 84 | Gu 80 | GW 84 


DTE 80{ 00000000 00000000 00000000 00000000 00000000 
C1) 
DTE 84] 00000000 00000000 00000000 00000000 00000000 
(2) 10000000 00000000 10000000 00000000 10000000 
GW 80 00000000 00000000 00000000 
C3) OvvvyvvyV Ovvvvvvv Ovyvvyvyy 
GW 84 00000000 00000000 00000000 
Ovuvyvvvyv OvvvvvvyY OvuvvvvyV 
lyvvvvvv Ovvvvvvyv lyvvvvvyv 
lnnnnnnn Onnnnnnn lnnnnnnn 


C1) In principle, DTEs complying with the 1980 version of X.25 should not issue causes 
with first bit (bit 8) set to 1. This 15 not checked by XI. 


Not applicable 


(2) For compliance with IS0 standard 8208 


(3) GW defined as X.25 1980 compatible should not transit cause values with bit 8 set 
to 1. This 1s not checked by XI 


TABLE 19.1/7X.25 Cpart 2 of 2) 


XI handling of resetting causes 


CAUSE QUALIFIER = SPECIFIC 


Destination 


DTE 80 DTE 84% | cw 80 GW 84 


00000000 00000000 00000000 00000000 00000000 
10000000 00000000 10000000 00000000 10000000 


GW 80 00000000 00000000 00000000 
C3) Ovvvvvvy Ovvvvvvyv Ovvvyvvvy 


GW 84 00000000 00000000 00000000 
Ovvvvvvy Ovvvvvvv Ovvvvvvv 
lyvvvvvv OvvvvvVvyV lyvvvvvv 
lnnnnnann Onnnnnnn Innnnnnn 


Not applicable 


---------------—- 


C1), €2), (€3) Same as above. 


5.4.3.2 Diagnostic Code 
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Octet 5 is the diagnostic code and contains additional information on the reason for 
the reset. 


In a reset request packet the diagnostic code is not mandatory. 


In a reset indication packet, if the resetting cause field indicates "DTE originated”, 
the diagnostic code has been passed unchanged from the resetting DTE. If the DTE 
requesting a reset has not provided a diagnostic code in its reset request packet, 
then the bits of the diagnostic code in the resulting reset indication packet will 
all be zeros. 


When a reset indication packet results from a restart request packet, the value of 
the diagnostic code will be that specified in the restart request packet, or all zeros 
in the case where no diagnostic code has been specified in the restart request packet. 


When the resetting cause field does not indicate "DTE originated”, the diagnostic code 
in a reset indication packet is network generated. Annex E lists the codings for 
network generated diagnostics. The bits of the diagnostic code are all set to 0 when 
no specified additional information for the reset is supplied. 


Note - The contents of the diagnostic code field do not alter the meaning of the cause 
field. A DTE is not required to undertake any action on the contents of the diagnostic 
code field. Unspecified code combinations in the diagnostic code field shall not 
cause the DTE to not accept the cause field. 


5.4.4 DTE and DCE Reset Confirmation Packets 


Figure 12/X.25 illustrates the format of the DTE and DCE reset confirmation packets. 
Bits 


General format identifier 


1 (see Note) 
0 
c 
t 2 
e 
t 
S 
3 


Note - Coded 0001 (modulo 8) or 0010 Cmodulo 128). 


FIGURE 12/7X.25 
DTE and DCE Reset Confirmation Packet Format 


5.5 RESTART PACKETS 


5.5.1 Restart Request and Restart Indication Packets 


Figure 13/X.25 illustrates the format of the restart request and restart indication 
packets. 
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Bits 


General format 
(see Note) 


pa 


0 2 
c 
t 
: ; Packet type identifier 
S 1 1 1 
4 Restarting cause 
5 Diagnostic code(a) 


(a) This field is not mandatory in restart request packets. 


Note - Coded 0001 (modulo 8) or 0010 Cmodulo 128). 


FIGURE 137X.25 


Restart Request and Restart Indication Packet Format 


5.5.1.1 Restarting Cause Field 
Octet 4 is the restarting cause field and contains the reason for the restart. 


©: restart request packets, the restarting cause field should be set by the DTE to 
one of the following values: 


bits : 876564321 
value : 0000000 0 
or : 1K XKXXXXKX 


where each X may be independently set to 0 or 1 by the DTE 


See the note below Table 20/X.25 for the values allowed for a DTE attached to an XI 
node. 


The DCE will prevent values of the restarting cause field other than those shown above 
from reaching the other end of the virtual calls and/or permanent virtual circuits 
by either accepting the restart request packet and forcing the clearing or resetting 
cause field to all Os in the corresponding clear and/or reset indication packets, or 
considering the restart request as an error and following the procedure described in 
Annex C. | 


| XI considers a not-permitted cause field issued by a DTE as an error and will take 
| the actions described in Annex C. 


The coding of the restarting cause field in the restart indication packets is given 
in Table 20/7X.25. 
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TABLE 20/7X.25 
Coding of the Restarting Cause Field in Restart Indication Packet 


Local procedure error 


Network congestion 
Network operational 
Registration/cancellation confirmed (a) 


Ca) May be received only if the optional online facility registration facility is 


or 


CRRENEGEREED SEES PED CY CYS WIMARD CSA CED STEAD GD CRUNED CED GRADS COG GEE GEARS CE GEES CT GN Se! GRRE GEKA Geer ga acne 


used 


The cause codes generated by a DCE in an XI node are controlled by a cause qualifier 
parameter. This parameter is chosen by the network provider to be either ‘standard’ 
*"specific': 


When the cause qualifier parameter value is "standard’, and the DTE has subscribed 
to the 1984 version of X.25, the values of the cause field for a DTE should be 
selected from Table 20/X.25. The values which may be sent to DTEs attached to 
the XI network are those in Table 20/X.25. 


However, when clears or resets resulting from the restart are passed to a PSDN 
through the GW-DTE function, bit 8 of the cause is set to 1 so as to comply with 
the Recommendation, irrespective of the origin of the restart (the DTE on the XI 
network or the XI network itself) provided the PSDN accepts it (see Tables 
18.1/X.25 and 19.1/X%.25). 


When the cause qualifier parameter value is "specific”, and the DTE has subscribed 
to the 1980 version of X.25, the only value permitted to DTEs attached to an XI 
node is all 0s, Cotherwise it is a procedure error). The values generated by the 
XI network are those shown in Table 20/7X.25 with bit 8 set to 1. Restart codes 
resulting in clears or resets and issued by a PSDN are those shown in Table 
20/7X.25, and thus can be differentiated from those issued by the XI network. A 
DTE attached to the PSDN will also be capable of differentiating the network 
origin of the clear or the reset resulting from a restart. Tables 18.1/X.25 and 
19.1/X.25 describe possible cause codes received by remote DTEs following a 
restart procedure in an XI network. 


5.5.1.2 Diagnostic Code 


Octet 5 1s the diagnostic code and contains additional information on the reason for 
the restart. 


In a restart request packet, the diagnostic code is not mandatory. The diagnostic 
code, if specified, 1s passed to the corresponding DIEs as the diagnostic code of a 
reset indication packet for permanent virtual circuits or a clear indication packet 
for virtual calls. 


The coding of the diagnostic code field in a restart indication packet is given in 
Annex E. The bits of the diagnostic code are all set to zero when no specific 
additional information for the restart is supplied. 


Note - The contents of the diagnostic code field do not alter the meaning of the cause 
field. A DTE is not required to undertake any action on the contents of the diagnostic 
code field. Unspecified code combinations in the diagnostic code field shall not 
cause the DTE to not accept the cause field. 


5.5.2 DTE and DCE Restart Confirmation Packets 


Figure 14/X.25 illustrates the format of the DTE and DCE restart confirmation packets. 
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Bits 


General format 
(see Note) 


Packet type identifier 
1 1 


Note - Coded 0001 (modulo 8) or 0010 (modulo 128). 


FIGURE 147X.25 


DTE and DCE restart confirmation packet format 


5.6 DIAGNOSTIC PACKET 
Figure 15/X.25 illustrates the format of the diagnostic packet. 


Bits 


General format identifier 
1 (see Note 1) 


Packet type identifier 
1 0 


non + MD 
N 


G Diagnostic code 


Diagnostic explanation 
5 (see Note 2) 


Note 1 - Coded 0001 (modulo 8) or 0010 (modulo 128). 


Note 2 - The figure is drawn assuming the diagnostic explanation field is an integral 
number of octets in length. 


FIGURE 157X.25 


Diagnostic packet format 


| The XI diagnostic explanation field contains always an integral number of octets. 
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5.6.1 Diagnostic Code Field 


Octet 4 is the diagnostic code and contains information on the error condition which 
resulted in the transmission of the diagnostic packet. The coding of the diagnostic 
code field is given in Annex E. 


5.6.2 Diagnostic Explanation Field 


When the diagnostic packet is issued as a result of the reception of an erroneous 
packet from the DTE (see Table C-1/X.25 and C-2/X.25), this field contains the first 
three octets of header information from the erroneous DTE packet. If the packet 
contains less than 3 octets, this field contains whatever bits were received. 


When the diagnostic packet is issued as a result of a DCE time-out (see Table 
D-1/X.25), the diagnostic explanation field contains 2 octets coded as follows: 


® Bits 8, 7, 6 and 5 of the first octet contain the general format identifier for . 
the interface; 


e Bits 4 to 1 of the first octet and bits 8 to 1 of the second octet are all 0 for 


expiration of time-out T10 and give the number of the logical channel on which 
the time-out occurred for expiration of time-out T12 or T13. 


5.7 PACKETS REQUIRED FOR OPTIONAL USER FACILITIES 


5.7.1 DTE Reject (REJ) Packet For the Packet Retransmission Facility 


The packet retransmission facility is not available with XI. 


5.7.2 Registration Packets for the Online Facility Registration Facility 


The online facility registration facility is not available with XI. 
5.8 XI ADDRESS FORMATS 


5.8.1 Architectural Considerations 


The configuration of an XI network is the responsibility of the network service 
provider who must decide: 


e The XI network addressing scheme, which assigns at least one "home DTE address", 
to each DTE within that XI network. CNote: In the remainder of this section, 
the word “address” without a qualifier means the "home DTE address”. ) 


e The length of the address (the number of digits of the home DTE address), which 
1s the same for all DTEs in a network, but may differ from one XI network to 
another, and must be less than or equal to 10. In an X.25 environment, the digits 


of an address are BCD encoded and two digits are encoded in one byte in the address 
field. 


@ The value for the prefix of the DIE address, which specifies the syntax of the 
content of the address fields of X.25 packets. 


The routing process of XI takes into account two levels of hierarchy: 


1. The DTE per XI node (the "DTE number”) level, and 
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2. The XI node per XI network (the "XI node number") level. 


The format of an XI address (a "home DTE address”) is: 


Q@< 8 digits P < 8 digits 
<— (> 
DTE Number 
XI Node number Cin that XI node) 
< > 
N digits 


' P + @ $ 10 digits 


1 digit prefix : XI internal format indicated through RAP value 


FIGURE 5.8.171 


Format of the "home DTE address” in an XI network 


More than one address can be assigned to a particular DTE. When more than one address 
1s assigned, these addresses must be consecutive; the lowest address (the "generic 


address” ) must be a multiple of 10 exp.N. A subaddress is the difference between the 


DTE address and the generic address. All subaddresses from 0 to 10 exp.N - 1 are 
valid. 


The calling and called address fields of X.25 packets do not necessarily include the 
complete "home DTE address” format of DTEs belonging to the addressing scheme of an 
XI network. For example, calls within the same XI node may omit the XI node number. 
Communications may also be established with DTEs attached to external X.25 networks, 
such as public data networks. This is how XI allows non-XI address formats at the 

interface between a DTE and its XI access node. An XI address format is identified 


ne) in the address field of signalling packets exchanged at the interface between a 


©: an XI _ prefix. The XI prefix is defined as the first digit (the more significant 


TE and its access XI node. 

The two different address formats supported by XI are as follows: 

1. Internal format, Relative Address Prefix CRAP) 
With this format a portion of the "home DTE address” of a DTE, in the addressing 
scheme of the XI network, follows the prefix digit. The address digits in the 


XI addressing scheme are located after the prefix digit in the address field. 
The address portion may be: 


e A subaddress Conly in the calling DTE address field of the call request 


packet) 
e A "DTE number” within its access XI node 
e A "DTE number™ and an "XI node number” within the network addressing scheme, 


i.e., the complete "home DTE address” itself. 


The value for RAP is chosen by the network service provider. The relative address 
format is a variable format and permits DTEs to handle a short number of digits 
in the called DTE address field of call request packets when, for example, the 
called DTE is located on the same XI node as the calling DTE. 


2. External format 


This format is used for virtual calls between a DTE attached to an XI node and a 
DTE attached to a PSDN (for example, a Public Data Network), when the XI network 
has one or several GW-DTE connections with that PSDN. Such a format is identified 
in one of two ways, as described below: 
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e External address prefix (CXAP) 


With this format, the four digits after the prefix are interpreted by XI as 
the external PSDN identifier (Data Network Identification Code, or DNIC), and 
the remaining digits as the address of a DTE in the external PSDN addressing 
plan. Any prefix specific to the external network, is not part of this 
address. Instead, the GN-DTE function will either replace the XAP by the 
prefix required by the external PSDN, or will delete it Cif no prefix is 
required by the PSDN). 


° Default external address 
If the first digit is neither RAP nor XAP, then XI directs the call towards 


a default external PSDN: the first digit must then be the first digit which 
is required for addressing within that PSDN. 


If the default external addressing is used, then the value for RAP/XAP must 

be selected in the following way: 

= If the XI network is connected with a PSDN making use of specific 
prefixC€es), then eliminate from the choice of RAP/XAP any specific prefix 
value that has to be used for external calls. 

= If the XI network 1s connected with a PSDN making use of full X.121 
addresses, then eliminate from the choice of RAP/XAP the first digit (area 
code) of the DNIC of any PSDNs that have to be reached from the XI network 
as default external network. 

= Select the RAP/XAP values from the remaining values. 


The following sections describe how addresses are handled in an XI network. 


5.8.2 Addressing DTEs within an XI Network Using the RAP Format 


Figure 5.8.2/1 gives examples of address handling within an XI network. 


Example: 


Assuming RAP = 1 


Assuming the addressing scheme of the network is: 

= DTE number length: P = 3, 

= subaddresses/DTE: max = 10 (N = 1) 

= DTEs/XI node: max = 100 

= nodes/network: max = 10 (@ = 1) 

e Assuming the addressable elements are: 

= Node = 5 with DTE = 170, 180, 190 to 199 (multiaddress DTE) 
= Node = 2 with DTE = 140, 150. 
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DTE number XI node = 5 XI node = 2 DTE number 
Cin that node) Cin that node) 
[ve Jot 
| ss 
180 < : > 150 
a 
eae) eee 
197,...199 : 
X25 X.25 
format format 


Called Calling Called Calling Called Calling 
DTE DTE DTE DTE DTE DTE 
address address address address address address 


e Call 1 A local call within node = 5. The calling DTE (170) gives 
only the DTE number of the called DTE (180). XI inserts the node 
number (5). | 


° Call 2 A similar call towards DTE with generic address 190. The 
subaddress is 7. 


° Call 3 The calling DTE indicates a subaddress (7) which is added to 
the generic address (15190 + 7 = 15197). 


FIGURE 5.8.2/1 


Example of addressing within an XI network 


5.8.3 Addressing to and from a PSDN Connected to XI 


5.8.3.1 XI outbound calls 


The fact that the Called DTE is attached to a PSDN ("external DTE"™) is indicated by 
the first digit of the Called Address being different from RAP. 


If this digit is the XAP, then the routing function in the XI network will select the 
appropriate GW-DTE from the DNIC included in the Called Address (the 4 digits after 
the prefix). Before transmitting the Call to the external PSDN, the GW-DTE function 
of XI replaces the XAP by the prefix required by the external PSDN Cpossibly no 
prefix). 


If this digit 1s neither RAP nor XAP, then the routing function in the XI network will 
select a default GW-DTE. 


There is no need for the DTE attached to the XI network to handle complementary 
addressing mechanisms. 


5.8.3.2 XI inbound calls 
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The external DTE will have to handle complementary addressing mechanisms so as to be 
able to call a DTE attached to an XI network. Three possible mechanisms can be used: 


1. Extended addressing facilities (1984 version of X.25, see Annex G : 
Two formats of extended address field are accepted by XI: 


The non-OSI format, identical to the XI Programming RPQ format, supported for upward 
compatibility reasons. 


Byte 0 Facility code (Hexadecimal 'C9') 
Byte 1 Facility length Cin bytes) 
Byte 2 10xxxxxx 
10 _ Non OSI address marker 
XXXXXX number of digits in the conveyed address 
Byte 3-N XI address of the called DTE, prefixed by the RAP. 


The OSI format, which should be preferred 
Coding is as follows: 
Byte 0 Facility code (Hexadecimal 'C9*) 
Byte 1 Facility length Cin bytes) 
Byte 2 00xxxxxx 
00 OSI address marker 
XXXXXX number of digits in the NSAP 
Byte 3-P NSAP, which splits as follows 


Byte 3 Authority and Format Identifier CAFI): 36 (BCD coded) for CCITT, 
BCD encoding 


Byte 4-11 Initial Domain Identifier CIDI): PSDN address of the GW-DTE, 
right justified, padded with leading zeroes 


Byte 12-P Domain Specific Portion (DSP), which in turn splits as follows: 


Byte l2-N Reserved for compatibility with forthcoming standards 
on DSP addressing scheme. WN is a boundary defined by 
the network service provider time, for the whole XI 
network. 


Byte Ntl-P XI address of the called DTE, prefixed by the RAP (XI 
DTE), the XAP Cexternal DTE) or a an external PSDN 
specific prefix Cexternal DTE) 


2. Customized use of call user data field (CUDF): The format chosen for XI permits 
X.28 DTES attached to 1980 or 19384 PADs to issue calls requiring complementary 
addressing. The complementary address 18S encoded in CUDF, from the fifth byte. 
Each digit 18S encoded to comply with international alphabet No. 5 CASCII) in 
one byte. The last digit of the complementary address is either the last byte 
of CUDF or the byte located just before a carriage return or + (plus) character. 
A constraint is that a complementary address can only have up to 12 digits. 


Note: The use of CUDF is seen as a temporary solution which should preferably be 
replaced by the use of the extended addressing facilities of the 1984 version of X.25, 
when available on PSDN. Note that the XI address of a calling DTE will not be sent 
to a called DTE on a PSDN when the extended addressing facilities cannot be used (XI 
never changes the content of CUDF). 
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Extended addressing (making use of 1984 CCITT defined DTE facilities) or, if not 
available, CUDF will be used. The selected mechanism will further be referred to as 
the "address extension mechanism". 


As the GN-DTE selection is performed by the XI node there is no need for the DTEs 
ttached to the XI network to handle any addressing extension mechanism. GW-DTE 
election by the DTE attached to an XI node is not a feature of XI. 


A PSDN can transit SVCs between two XI networks. Similarly, an XI network can transit 
SVCs between two PSDNs. However, these capabilities can be barred by the XI network 
service provider, if, for instance, they conflict with national regulations of the 
country where the network is operated. 


3. Default call: This is a default DTE address, installed by the network service 
provider on the GW-DTE, applicable to all logical channels of this GW-DTE, and used 
as a called address for all XI inbound calls, when no valid XI address has been found 
neither in the called address extension facility, nor in the CUDF. 


Figure 5.8.3/1 is an example of addressing between an XI network and a PSDN. 
Example: 


e The same network Cas in 5.8.2) is assumed with a GN-DTE function in node=2. This 
GW-DTE function is attached to a PSDN which makes use of specific prefixes (2). 
The GNW-DTE has a PSDN address 29701 and the DTE attached to PSDN has the address 
29802. 


e With call 1, the calling DTE may optionally include a complementary calling DTE 
address field, which is delivered to the called DTE y 

e With call 2, the GNW-DTE moves the XI address of the called DTE from the 
complementary called DTE address field to the called DTE address field. The 
complementary called DTE address is delivered to the called DTE. The DTE attached 
to the PSDN selects subaddress 7 of the DTE with generic address = 5190 
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|} DTE number XI network DTE PSDN 
in XI net. address 


PSDN 


XI INTERNAL 
FORMAT 


Calling Called Calling Called Calling 
DTE DTE DTE DTE DTE 
address address address address address 
7 7 4 
complem.| complem.| complem.]| complem. 
called calling called calling 
DTE DTE DTE DTE 
address address address address 


Note 1 — The calling DTE address is not given by the GN-DTE, but inserted by PSDN. © 


Note 2 — The complementary calling address is placed optionally by the calling DTE, 
only in the case when the extended addresses facilities can be used (X.25 1984 
parameter). 


FIGURE 5.8.3/1 


Example of addressing to and from a PSDN 
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| 5.8.4 Summary of DTE Address Formats in an XI Network 


| e Addressing within an XI network through prefix RAP 
Q< 8 DIGITS P < 8 DIGITS 
>< 


DTE number 
XI node number Cin that XI node) Subaddress 


. <——————___—> 
N digits 
ESS 


A 


: P + QQ <¢ 10 digits 
1 digit prefix : XI internal format indicated through RAP value 


° Abbreviated address formats in call request packets 
Calling DTE address: Called DTE address: 
0 digit ~ 
1 digit = prefix RAP = 
14+N digits = 
1+P digits 1#P digits Clocal calls only) 
1+P4+Q digits | 1+P+Q digits Cremote/local calls) 


Addressing to and from PSDN 


> | 150 digits nx. 
X 
E DNIc X.121 address 
P 
OR 
146-1 ts nex. > 
DNIcC X.121 address 
| | 
OR 
| | . 
—— 15 hUdigits max. > 


P| Specific Format 


ah 
v 


First digit of the address (value different from RAP and XAP) 


a 


5.8.5 Address Handling at the DTE/DCE Interface 


| 
| 
| Previous sections describe the behaviour of XI nodes in the case of call request and 
} incoming call packets, and which addresses are sent within the XI network. However, 
1 XI is designed to offer compatibility with the version 1984 of X.25 which permits 

| address handling in call accepted, call connected, clear request, clear indication, 

| and clear confirmation packets. The XI behaviour in each case where the calling 

] and/or the called DTEs have subscribed to the XI parameter ™X.25 1984" or "X.25 1980" 
| is described in 5.8.5.1-6. 
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5.8.5.1 Call Accepted Packet 


The called DTE may or may not insert addresses. The same rules as for the call request 
packet apply (see 5.8.2 and 5.8.3), plus the following rules: 


@ The calling DTE address Cif present) must be identical to the calling DTE address 
in the incoming call packet. Its format may be changed to one of the permitted 
formats shown in 5.8.4. 


° The called DTE address Cif present) must be identical to the called DTE address 
in the incoming call packet when the called DTE 15 only assigned a single address 
(no subaddressing). If there is subaddressing, the called DTE can change the 
subaddress field to any value. 


5.8.5.2 Call Connected Packet 

The call connected packet contains the calling and called DTE addresses. (If there 
is subaddressing, the called DTE can change the generic address to one of the 
addresses of the DTE.) 

5.8.5.3 Clear Request Packet 


The clearing DTE may or may not insert addresses. The same rules as for the call 
request packet apply (see 5.8.2 and 5.8.3), plus the following rules: 


e The calling DTE address Cif present) must be identical to the calling DTE address 
in the incoming call packet. The clearing DTE may change its format to one of 
the permitted formats shown in 5.8.4. 


e The called DTE address (if present) must be identical to the called DTE address 
in the incoming call packet when the called DTE is only assigned a single address 
(no subaddressing). If there is subaddressing, the called DTE can change the 
subaddress field to any value. 


The validity of the addresses are not checked by XI. 


5.8.5.4 Clear Indication Packet 


If the clear indication extended format is used by the DCE, i.e if the DTE is X.25 
1984 compatible and facilities are to be delivered to this DTE, then the clear 


indication packet contains the calling and called DTE addresses, as for the call 
connected packet. . 


5.8.5.5 DCE Clear Confirmation 


As the charging information facility is not available with XI, the DCE clear 
confirmation packet does not include any address. 


5.8.5.6 DTE Clear Confirmation 


X.25 Cand XI) does not allow addresses in the DTE clear confirmation packet. 


5.9 COMPATIBILITY BETWEEN 1980 AND 1984 VERSIONS OF X.25 


The formats of packets at the DTE/DCE interface are basically those of the X.25 
Recommendation, 1984 version. XI also supports the DTEs based on the 1980 version 


of the Recommendation, by means of a subscription parameter (X.25 version 1980 or 
1984). 


When a DTE subscribes to the 1980 version of X.25, the DCE will issue packets only 
in the 1980 format; therefore new facilities which require new formats are not passed 
to the DTE. The design of new facilities in X.25 is, in principle, so that an "old"™ 
DTE ren continue to be operated without being aware of the content of these 
facilities. 
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The differences in packet formats between the 1980 version and the 1984 version of 
Recommendation X.25 are listed in Annex H. The following describes how XI acts upon 
DTEs based on the 1984 version of X.25 and those based on the 1980 version. 


e The data field of the interrupt packet may be up to 32 bytes with the X.25 1984 
version, whereas it is limited to one byte in the 1980 version. In the case where 
a DTE, which has subscribed to the 1984 version, tries to send an interrupt packet 
with a data field larger than one byte towards a DTE which has subscribed to the 
1980 version, this interrupt packet is delivered. 


@ If a "1984 DTE”"™ tries to call a "1980 DTE”™ with 1984 CCITT-~specified DTE 
facilities in the facilities field, the call is delivered to the called DTE. 


e The size of the facility field in incoming call and call connected packets will 
not be greater than 63 octets for "1980 DTEs” 
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6. PROCEDURES FOR OPTIONAL USER FACILITIES (PACKET LEVEL ) 


6.1 ONLINE FACILITY REGISTRATION 


| The online facility registration facility 1s not applicable in the XI environment. 


6.2 EXTENDED PACKET SEQUENCE NUMBERING 


Extended packet sequence numbering is an optional user facility agreed for a period 
of time. It is common to all logical channels at the DTE/DCE interface. 


This user facility, if subscribed to, provides sequence numbering of packets performed 
modulo 128. In the absence of this facility, the sequence numbering of packets is 
performed modulo 8. 


6.3 D BIT MODIFICATION 


| The D bit modification facility is not applicable in the XI environment. 


6.4% PACKET RETRANSMISSION 


| The packet retransmission facility is not applicable in the XI environment. 


6.5 INCOMING CALLS BARRED 


Incoming calls barred is an optional user facility agreed for a period of time. This 


facility applies to all logical channels used at the DTE/DCE interface for virtual 
calls. | 


This user facility, if subscribed to, prevents incoming virtual calls from being 
presented to the DTE. The DTE may originate outgoing virtual calls. 


| It is the responsibility of the network service provider to check that the 
subscription to this facility by a DTE is consistent with the definition of the ranges 
| of logical channels at the DTE/DCE interface. 
Note 1 - Logical channels used for virtual calls retain their full duplex capability. 


Note 2 - XI does not allow a virtual call to be sent to the DTE when the called address 
is the address of the calling DTE. 
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6.6 OUTGOING CALLS BARRED 


Outgoin calls barred is an optional user facility agreed for a period of time. This 
facility applies to all logical channels used at the DTE/DCE interface for virtual 


eq 
his user facility, if subscribed to, prevents the DCE from accepting outgoing virtual 
calls from the DTE. The DTE may receive incoming virtual calls. 


[f It is the responsibility of the network service provider to check that the 
subscription to this facility by a DTE is consistent with the definition of the ranges 
| of logical channels at the DTE/DCE interface. 


Note - Logical channels used for virtual calls retain their full duplex capability. 


6.7 ONE-WAY LOGICAL CHANNEL OUTGOING 


One-way logical channel outgoing is an optional user facility agreed for a period of 
time. This user facility, if subscribed to, restricts the logical channel use to 
originating outgoing virtual calls only. 


Note - A logical channel used for virtual calls retains its full duplex capability. 


The rules according to which logical channel group numbers and logical channel numbers 


can be assigned to one-way outgoing logical channels for virtual calls given in Annex 
A. 


Note - If all the logical channels for virtual calls are one-way outgoing at a DIE/DCE 


interface, the effect is equivalent to the incoming calls barred facility (see s. 6.5, 
particularly Note 2). 


6.8 ONE-WAY LOGICAL CHANNEL INCOMING 


ne-wa lo ical channel incoming is an optional user facility agreed for a period of 
ime. This user facility, if. subscribed to, restricts the logical channel use to 
receiving incoming virtual calls only. 


Note - A logical channel used for virtual calls retains its full duplex capability. 


The rules according to which logical channel group numbers and logical channel numbers 
can be assigned to one-way incoming logical channels for virtual calls are given in 
Annex A. 


Note - If all the logical channels for virtual calls are one-way incoming at a DTE/DCE 
interface, the effect is equivalent to the outgoing calls barred facility (see 6.6). 


6.9 NON-STANDARD DEFAULT PACKET SIZES 


Non-standard default packet sizes 1S an optional user facility agreed for a period 
of time. This facility, if subscribed to, provides for the selection of default 
packet sizes from the list of packet sizes supported by the Administration. Some 
networks may constrain the packet sizes to be the same for each direction of data 
transmission across the DTE/DCE interface. In the absence of this facility, the 
default packet sizes are 128 octets. 


| XI does not constrain packet sizes to be the same for each direction of data 
transmission. 


Note - In this section, the term “packet sizes" refers to the maximum user data field 
lengths of DCE data and DTE data packets. 


Values other than the default packet sizes may be negotiated for a virtual call by 
means of the flow control parameter negotiation facility (see 6.12). Values other 
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than the default packet sizes may be agreed for a period of time for each permanent 
virtual circuit. 


6.10 NON-STANDARD DEFAULT WINDOW SIZES 


Non-standard default window sizes 15 an optional user facility agreed for a period 
of time. This facility, if subscribed to, provides for the selection of default 
window sizes from the list of window sizes supported by the Administration. Some 
networks may constrain the default window sizes to be the same for each direction of 
data transmission across the DTE/DCE interface. In the absence of this facility, the 
default window sizes are 2. 


XI does not constrain window sizes to be the same for each direction of data 
transmission. 


Values other than the default window sizes may be negotiated for a virtual call by 
means of the flow control parameter negotiation facility (see 6.12). Values other 
than the default window sizes may be agreed for a period of time for each permanent 
virtual circuit. 


6.11 DEFAULT THROUGHPUT CLASSES ASSIGNMENT 


Default throughput classes assignment is an optional user facility agreed for a period 
of time. This facility, if subscribed to, provides for the selection of default 
throughput classes from the list of throughput classes supported by the 
Administration. Some networks may constrain the default throughput classes to be the 
same for each direction of data transmission. In the absence of this facility, the 
default throughput classes correspond to the user class of service of the DTE (see 
7.2.2.2) but do not exceed the maximum throughput class supported by the network. 


The default throughput classes are the maximum throughput classes which may be 
associated with any virtual call at the DTE/DCE interface. Values other than the 
default throughput classes may be negotiated for a virtual call by means of the 
throughput class negotiation facility (see 6.13). Values other than the default 
eA ae lies classes may be agreed for a period of time for each permanent virtual 
circuit. | 


XI requires that default throughput classes, if explicitly subscribed to, be lower 
than or equal to the user class of service (the DTE access link speed). 


XI does not constrain throughput classes to be the same for each direction of data 
transmission. 


The maximum throughput class supported by an XI network depends upon the network 
configuration and is the responsibility of the network service provider. 


6.12 FLOW CONTROL PARAMETER NEGOTIATION 


Flow control parameter negotiation is an optional user facility agreed for a period 
of time which can be used by a DTE for virtual calls. This facility, if subscribed 
to, permits negotiation on a per call basis of the flow control parameters. The flow 
control parameters considered are the packet and window sizes at the DTE/DCE interface 
for each direction of data transmission. 


Note - In this section, the term "packet sizes” refers to the maximum user data field 
lengths of DCE data and DTE data packets. 


In the absence of the flow control parameter negotiation facility, the flow control 
parameters to be used at a particular DTE/DCE interface are the default packet sizes 
(see 6.9) and the default window sizes (see 6.10). 


When the calling DTE has subscribed to the flow control parameter negotiation 

facility, it may request packet sizes and/or window sizes for both directions of data 
transmission (see 7.2.1 and 7.2.2.1). If particular window sizes are not explicitly 
requested ina call request packet, the DCE will assume that the default window sizes 
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were requested for both directions of data transmission. If particular packet sizes 
are not explicitly requested, the DCE will assume that the default packet sizes were 
requested for both directions of data transmission. 


When a called DTE has subscribed to the flow control parameter negotiation facility, 


e::. incoming call packet will indicate the packet and window sizes from which DTE 


egotiation can start. No relationship needs to exist between the packet sizes (P) 
and window sizes (W) requested in the call request packet and those indicated in the 


Incoming call packet. 


| In the case where the incoming call packet indicates the flow control parameters 


| negotiation facility, XI will indicate to the DTE values for packet sizes and window 
sizes as follows : 


e The packet sizes indicated to the called DTE will be the packet sizes selected 
by the calling DTE, if any, or the default packet sizes of the calling DTE. 


© The window sizes indicated to the called DTE will be the default window sizes of 
the called DTE. 


The called DTE may request window and packet sizes with facilities in the call 
accepted packet. The only valid facility requests in the call accepted packet, as a 
function of the facility indications in the incoming call packet, are given in Table 
22/X.25. If the facility request is not made in the call accepted packet, the DTE 
is assumed to have accepted the indicated values (regardless of the default values) 
for both directions of data transmission. 


TABLE 22/7X.25 


Valid Facility Requests in Call Accepted Packets in 
Response to Facility Indications in Incoming Call Packets 


Facility indication Valid facility request 


W Cindicated) 2 W Cindicated) 
W Cindicated) W Crequested) 
@ P Cindicated) 2 P Cindicated) 2 P Crequested) 2 128 


P Cindicated) 128 2 P Crequested) 2 P Cindicated) 


When the calling DTE has subscribed to the flow control parameter negotiation 
facility, every call connected packet will indicate the packet and window sizes to 
be used at the DTE/DCE interface for the call. The only valid facility indications 
in the call connected packet, as a function of the facility requests in the call 
request packet, are given in Table 23/X.25. 


TABLE 23/7X.25 


Valid Facility Indications in Call Accepted Packets in 
Response to Facility Requests in Call Request Packets 


Facility request Valid facility indication 


W Crequested) W Crequested) 
W Crequested) W Cindicated) 


P Crequested) 2 P (Crequested) 1 icated) 2 128 


1 
P (requested) 128 2 P Cindicat P (requested) 
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The network may have constraints requiring the flow control parameters used for a call 
to be modified before indicating them to the DTE in the incoming call packet or call 
connected packet; that is, the ranges of parameter values available on various 
networks may differ. 


In the case where the call connected packet tndicates the flow control parameters 
negotiation facility, XI indicates to the DTE values for packet sizes and window sizes 
chosen as follows: 


The packet sizes indicated to the calling DTE will be the packet sizes negotiated 
with the called DTE, if any» or the default packet sizes of the called DTE if they 
comply with the rules depicted in Table 23/X.25, or otherwise the packet sizes 
selected by the calling DTE. 


e The window sizes indicated to the calling DTE will be the window sizes requested 
by the calling DTE, if any» or the default window sizes of the calling DTE. 


XI policy in flow control parameters negotiation is to try to get the same packet sizes 
at both ends. When the default packet sizes of the calling and the called DTEs are 
not identical, this can be achieved if at least one of the calling or called DTEs has 
subscribed to the flow control parameters negotiation facility. Moreover, if only 
the called DTE has subscribed to the flow control parameters negotiation facility, 
the equality of packet sizes at both ends requires that the called DTE accepts the 
values proposed by the network; if only the calling DTE has subscribed to the flow 
control parameters negotiation facility, the equality of packet sizes at both ends 
requires that the called DTE default packet sizes be identical or closer to the 
standard (128) than the default packet sizes requested by the calling DTE or, in the 
absence of such a request, than the calling DTE default packet sizes. This situation, 
where packet sizes are the same at both the calling and called DTE avoids packets 
blocking/segmenting and thereby improves performance. 


In the case where flow control parameters negotiation is subscribed, the default 
Window sizes are taken as the basis for negotiation by the DCE. The default window 
sizes should be chosen with the different criteria when flow control parameters 
negotiation jis subscribed than when it is not subscribed. 


Window and packet sizes need not be the same at each end of a virtual call. 


6.13 THROUGHPUT CLASS NEGOTIATION 


Throughput class negotiation facility 1s not applicable in the XI environment. 


When neither the calling DTE nor the called DTE has subscribed to the throughput class 
negotiation facility, the throughput classes applying to the virtual call will not 
be higher than the ones agreed as defaults at the calling and called DTE/DCE 
interfaces. They may be further constrained to lower values by the network, that is, 
for international service. 
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Note 1 - Since both throughput class negotiation and flow control parameter 
negotiation (see 6.12) facilities can be applied to a Single call, the achievable 
throughput will depend on how users manipulate the D bit. 


ote 2 - Users are cautioned that the choice of too small a window and packet size 
f a DTE/DCE interface (made by use of the flow control parameter negotiation 
facility) may adversely affect the attainable throughput class of a virtual call. 
This 1s likewise true of flow control mechanisms adopted by the DTE to control data 
transmission from the DCE. 


6.14 CLOSED USER GROUP RELATED FACILITIES 


The set of closed user group (CUG) optional user facilities enables users to form 
groups of DTEs to and/or from which access is restricted. Different combinations of 
access restrictions to and/or from DTEs having one or more of these facilities result 
in various combinations of accessibility. 


A DTE may belong to one or more CUGs. Each DTE belonging to at least one CUG has 
either the closed user group facility (see 6.14.1) or one or both of the closed user 
group with outgoing access and the closed user group with incoming access facilities 
(see 6.14.2 and 6.14.3). For each CUG to which a DTE belongs, either or none of the 
incoming calls barred within a closed _ user group or the outgoing calls barred within 
a closed user group facilities (see 6.14.4 and 6.14.5) may apply for that DTE. 
eee combinations of CUG facilities may apply for different DTEs belonging to 

e same CUG. 


When a DTE belonging to one or more CUGs places a virtual call, the DTE may explicitly 
indicate in the call request packet the CUG selected by using the closed user group 
selection facility (see 6.14.6) or the closed user group with outgoing access 
selection facility (see 6.14.7) Csee Noted. When a DTE belonging to one or more CUGs 
receives a virtual call, the CUG selected may be explicitly indicated in the incoming 
call packet through the use of the closed user group selection facility or the closed 
user group with outgoing access selection facility. 


Note - For a given virtual call, only one of the above mentioned selection facilities 


oe" be present 
he number of CUGs to which a DTE can belong is network dependent. In an XI network, 
{ a DTE may subscribe to up to 100 CUGs (0 to 99). 


6.14.1 Closed User Group 


Closed user group 1s an optional user facility agreed for a period of time for virtual 
calls. This user facility, if subscribed to, enables the DTE to belong to one or more 
closed user groups. A closed user group permits the DTEs belonging to the group to 

communicate with each other but precludes communication with all other DTEs. 


When the DTE belongs to more than one closed user group, a preferential closed user 


group must be specified. In an XI network, a DTE may subscribe to up to 100 CUGs (0 
to 99) 


6.14.2 Closed User Group with Outgoing Access 


Closed user group with outgoing access 15 an optional user facility agreed for a 
period of time for virtual calls. This user facility, if subscribed to, enables the 
DTE to belong to one or more closed user groups (as in 6.14.1) and to originate virtual 
calls to DTEs in the open part of the network (that is, DITEs not belonging to any 
closed user group) and to DTEs belonging to other CUGs with the incoming access 
capability. 


When the closed user group with outgoing access facility is subscribed to and the DTE 


has a preferential CUG, then only the closed user group selection facility (as in 
6.14.6) 1s applicable for use at the interface. 
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When the closed user group with outgoing access facility is subscribed to and the 
network offers to the DTE the capability of choosing whether or not to have a 
preferential CUG (that is, the closed user group with outgoing access selection 
facility (see 6.14.7) 1s offered by the network), and the DTE has no preferential CUG, 


then both the closed user group selection and the closed user group with outgoing 
access selection facilities are applicable for use at the interface. 


6.14.3 Closed User Group with Incoming Access 


Closed user group with incoming access 18S an optional user facility agreed for a 
period of time for virtual calls. This user facility, if subscribed to, enables the 
DTE to belong to one or more closed user groups (as in 6.14.1) and to receive incoming 
calls from DTEs in the open part of the network (that is, DTEs not belonging to any 
closed user group) and from DTEs belonging to other CUGs with the outgoing access 
capability. 


When the closed user group with incoming access facility is subscribed to and the DTE 
has a preferential CUG, then only the closed user group selection facility is 
applicable for use at the interface. 


When the closed user group with incoming access facility is subscribed to and the 
network offers to the DTE the capability of choosing whether or not to have a 
preferential CUG (that is, the closed user group with outgoing access selection 
facility is offered by the network), and the DTE has no preferential CUG, then both 


the closed user group selection and the closed user group with outgoing access 
selection facilities are applicable for use at the interface. 


6.14.4 Incoming Calls Barred within a Closed User Group 


Incoming calls barred within a closed user group is an optional user facility agreed 
for a period of time. This user facility, if subscribed to for a given closed user 
group, permits the DTE to originate virtual calls to DTEs in this closed user group, 
but precludes the reception of incoming calls from DTEs in this closed user group. 


6.14.5 Outaoing calls Barred within a Closed User Group 


Outgoing calls barred within a closed user group is an optional user facility agreed 
for a period of time. This user facility, if subscribed to for a given closed user 

group, permits the DTE to receive virtual calls from DTEs in this closed user group, 
but prevents the DTE from originating virtual calls to DTEs in this closed user group. 


6.14.6 Closed User Group Selection 


Closed user group selection is an optional user facility which may be used on a per 
virtual call basis. This facility may be requested or received by a DTE only if it 
has subscribed to the closed user group facility, or the closed user group with 

outgoing access facility and/or the closed user group with incoming access facility. 


The closed user group selection facility (see 7.2.1 and 7.2.2.3) may be used by the 


calling DTE in the call request packet to specify the closed user group selected for 
a virtual call. 


The closed user group selection facility is used in the incoming call packet to 
indicate to the called DIE the closed user group selected for a virtual call. 


The number of closed user groups to which a DTE can belong is network dependent. If 
the DTE belongs to 100 or fewer closed user groups, the basic format of the closed 
user group selection facility must be used. If the DTE belongs to between 101 and 
10000 closed user groups, the extended format of the closed user group selection 
facility must be used. 


92 XI DTE/DCE Interface Description 


Sef ee - 


IBM Confidential 


| As XI permits a DTE to belong to up to 100 closed user groups, only the basic format 
| is used by the DCE, and is to be used by the DTE. 


The appearance ina call request packet of both formats or of a format inconsistent 
with the number of CUGs subscribed to will be treated as a facility code not allowed. 


he significance of the closed user group selection facility in call request packets 
1S given in Table 24/X.25 and in incoming call packets is given in Table 25/X.25. 


6.14.7 Closed User Group with Outgoing Access Selection 


Closed user group with outgoing access selection is an optional user facility which 
may be used ona per virtual call basis. This facility may be requested by a DTE only 
if the network supports it and the DTE has subscribed to the closed user group with 
outgoing access facility or to both the closed user group with outgoing access and 
closed user group with incoming access facilities. This facility may be received by 
a DTE only if the network supports it and the DTE has subscribed to the closed user 
group with incoming access facility or to both the closed user group with incoming 
access and closed user group with outgoing access facilities. 


The closed user group with outgoing access selection facility (see 7.2.1 and 7.2.2.4) 
may be used by the calling DTE in the call request packet to specify the closed user 
group selected for a virtual call and to indicate that outgoing access is also 
desired. 


The closed user group with outgoing access selection facility is used in the incoming 
call packet to indicate to the called DTE the closed user group selected for a virtual 
call and that outgoing access had applied at the calling DTE. 


The closed user group with outgoing access selection facility can only be present in 
the facility field of call set-up packets if the DTE does not have a preferential 
closed user group. 


The number of closed user groups to which a DTE can belong is network dependent. If 
the DTE belongs to 100 or fewer closed user groups, the basic format of the closed 
user group with outgoing access selection facility must be used. If the DTE belongs 


o between 101 and 10 000 closed user groups, the extended format of the closed user 
roup with outgoing access selection facility must be used. 
As XI permits a DTE to belong to up to 100 closed user groups, only the basic format 
is used by the DCE, and is to be used by the DTE. 


The appearance ina call request packet of both formats or of a format inconsistent 
with the number of CUGs subscribed to will be treated as a facility code not allowed. 


The significance of the presence of the closed user group with outgoing access 
selection facility in call request packets 1s given in Table 24/X.25 and in incoming 
call packets 1s given in Table 25/X%.25. 


6.14.8 Absence of Both CUG Selection Facilities 


The significance of the absence of both the closed user group selection facility and 
the closed user group with outgoing access selection facility in call request packets 
is given in Table 24/X.25 and in incoming call packets 1s given in Table 25/7X.25. 
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TABLE 24/7X.25 


Meaning of Closed User Group Facilities in a Call Request Packet 


Contents of call |Closed user Closed user Neither closed 

request packet group selectionigroup with user group 

(see Note 2) -—>i facility outgoing access |selection nor 
selection closed user 

Closed user group facility group with 

subscription of outgoing access 

the calling DTE | selection 

(see Note 1) V facility 


CUG with CUG specified Not allowed Preferential or 
preferential (see Note 4) (call cleared) only CUG 
(see Note 3) (see Note 4) 


Preferential or 
only CUG + out— 
going access 
CUG specified (see Notes 5, 6) 
+ outgoing 
access Not allowed 
(see Note 4) (call cleared) 


CUG specified CUG specified + |Outgoing access 
(see Note 4) outgoing access 
(see Notes 5, 6) 


No CUG Not allowed Not allowed 
(call cleared) {(€call cleared) 


OA: Outgoing access 
IA: Incoming access 


Note 1 - The order of subscription types is different from Table 25/X.25. 

Note 2 - The inclusion of both the closed user group selection facility and the closed 
user group with outgoing access selection facility is not allowed in the call request 
packet. 

Note 3 - CUG without preferential is not allowed. 

Note 4 - If outgoing calls are barred within the specified CUG or within the 
preferential or only CUG, then the call is cleared. 

Note 5 - If outgoing calls are barred within the specified CUG or within the 
preferential or only CUG, then only outgoing access applies. 

Note 6 - For international calls, if the destination network does not support the 
closed user group with outgoing access selection facility, the call may be cleared 
even if the called DTE belongs to the specified closed user group or to the open world 
or has incoming access. 
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Contents of 
Incoming call 
packet 


Closed user group 


subscription of 
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TABLE 25/7X.25 


Closed user 


group selection 
—>ifacility 


Closed user 
group with 
outgoing access 
selection 
facility 


Neither closed 
user group 
selection nor 
closed user 
group with 
outgoing access 


the called DTE | 
(see Note 1) V 


CUG with 
preferential 
(see Note 2) 


selection 
facility 


CUG specified 
(see Note 3) 


Preferential or 
only CUG 
(see Note 3) 


Not applicable 


Preferential or 
only CUG + in- 
coming access 
CUG specified (see Note 5) 
+ Incoming 
access 
(see Note 4) 


Not applicable 


CUG specified 
Csee Note 3) 


CUG specified + 
Incoming access 
(see Note 4) 


Incoming access 


CUG/IA without 
preferential 


Not applicable |Not applicable 


Outgoing access 
Incoming access 


@: 


Note 1 - The order of subscription types is different from Table 24/X.25. 
Note 2 - CUG without preferential 


15 not allowed. 


Note 3 - When incoming calls are barred within this CUG, the call is blocked; there 
is no incoming call. 
Note 4 - When incoming calls are barred within this CUG, only incoming access applies 


and the incoming call packet carries neither the closed user group selection nor the 
closed user group with outgoing access selection facility. 


Note 5 - When incoming calls are barred within this CUG, only incoming access applies. 
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6.15 BILATERAL CLOSED USER GROUP RELATED FACILITIES 


| The bilateral closed user group facility is not applicable in the XI environment. 


6.16 FAST SELECT 


| The fast select facility is not applicable in the XI environment. 


6.17 FAST SELECT ACCEPTANCE 


| The fast select acceptance facility is not applicable in the XI environment. 


6.18 REVERSE CHARGING 


Reverse charging 15 an optional user facility which may be requested by a DTE for a 
given virtual call (see 7.2.1 and 7.2.2.6). 


6.19 REVERSE CHARGING ACCEPTANCE 


Reverse charging acceptance 1s an optional user facility agreed for a period of time 
for virtual calls. This user facility, if subscribed to, authorizes the DCE to 
transmit to the DTE incoming calls which request the reverse charging facility. In 
the absence of this facility, the DCE will not transmit to the DTE incoming calls which 
request the reverse charging facility. 


6.20 LOCAL CHARGING PREVENTION ® 


| The local charging prevention facility is not applicable in the XI environment. 


6.2] NETWORK USER IDENTIFICATION 


| The network user identification facility is not applicable in the XI environment. 


6.22 CHARGING INFORMATION 


| The charging information facility is not applicable in the XI environment. 
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6.23 RPOA SELECTION 


| The RPOA selection facility is not applicable in the XI environment. 


@.. HUNT GROUP 


| The hunt group facility is not applicable in the XI environment. 


6.25 CALL REDIRECTION 


Call redirection 75 an optional user facility agreed for a period of time. This user 
facility, if subscribed to, redirects incoming calls destined to this DTE when: 


1. The DTE is out of order, or 
2. The DTE is busy. 


Some networks may provide call redirection only in case of 1. Some networks may 
offer, in addition: | 


3. Systematic call redirection due to a prior request by the subscriber. 


The basic service is Limited to one call redirection. In addition, some networks may 
offer either one of the following (mutually exclusive) capabilities: 


1. A list of alternate DTEs (C1, C2, etc.) is stored by the network of the originally 
called DTE (DTE B). Consecutive attempts of call redirection are tried to each 
of these addresses, in the order of the list, up to the completion of the call; 


2. Call redirections may be logically chained; if DTE C has subscribed to call 
redirection to DTE D, a call redirected from DTE B to DTE C may be redirected to 
DTE D. 


€. any case, networks will ensure that loops are avoided and that the connection 
establishment phase has a limited duration, consistent with the DTE time Limit T2l1 
(see Table D-2/7X.25). 


If a call is cleared by the network as a consequence of the redirection actions, the 
clearing cause 1S 1n principle the one generated at the last reached DTE/DCE 
interface. However, this point requires further study. 


Call redirection is limited to the network of the DTE originally called. 


When the virtual call is redirected, the clear indication packet (when no call 
accepted packet has been transmitted) or the call connected packet transferred to the 
calling DTE will contain the called address of the alternate DTE and the called line 
address modified notification facility (see 6.26), indicating the reason why the 
called address is different from the one originally requested. 


When the virtual call is redirected, some networks may indicate to the alternate DTE 
that the call was redirected, the reason for redirection and the address of the 
originally called DTE, using the call redirection notification facility (see 6.27) 
in the incoming call packet. 


The order of call set-up processing at the originally called DCE as well as the 
alternate DCE will be according to the sequence of call progress signals in Table 
1/X.96. For those networks that provide systematic call redirection with the prior 
request of the called DTE, the systematic call redirection request will have the 
highest priority in the call set-up processing sequence at the originally called DCE. 


It is for further study whether there is a need for an optional user facility for the 
calling DTE to indicate whether or not a redirection of a call originated by this DTE 
1s permitted. 


| XI supports the 3 possible causes of redirection, that is, DTE busy, DTE out-of-order, 


{ systematic redirection. Only one alternate DTE can be defined for the originally 
eo * DTE. The maximum number of chained redirections is defined by the network 
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service provider. The call redirection facility can be subscribed for an X.25 1980 
or X.25 1984 compatible DTE. The called line address modified notification facility 
and call redirection notification facility are delivered only to X.25 1984 compatible 
DTEs. 


When using the basic call redirection, the called address delivered to the final DTE 
15 the final DTE address (not the absent DTE address). 


6.25.1 Call redirection in association with SNBU 


The call redirection facility may be used in SNBU situations to facilitate DTE 
operations, by permitting a DTE temporarily attached to a back-up port through a 
switched connection, to be accessed with the same address as for normal operation from 
other DTEs. The call redirection remains optional for SNBU. 


The SNBU call redirection exhibits the following differences from the basic call 
redirection: 


e The absent DTE is the DTE which is to be secured through the port (i.e. through 
the DCE occurrence) relative to the final DTE 


° If a call is redirected towards a DCE working in SNBU mode, no more redirections 
are permitted from that DCE, even if the subscription parameters indicate such a 
possibility and if the maximum number of redirections is not reached. 


e The redirection is installed by the network operator on the absent DTE port at 
the time the failing leased access line is to be temporarily replaced by the 
switched connection 


e The absent DTE address will be delivered in the called address field of the 
incoming call packet, to the alternate DTE. 


e The alternate DCE will accept in the call accepted packet a called address equal 
to the address of the absent DTE 


e The called line address modified notification facility will be delivered to the 
calling DTE in the call connected packet, if is is subscribed as an X.25 1984 
compatible DTE. 


@ The alternate DTE address will be delivered to the calling DTE in the called 
address field of the call connected packet 


The Call redirection in association with SNBU has priority over other reasons for 
redirection (systematic, out of order, busy). 


6.26 CALLED LINE ADDRESS MODIFIED NOTIFICATION 


Called line address modified notification is an optional user facility used by the 
DCE in the call connected or clear _ indication packets to inform the calling DTE why 
the called address in the packet is different from that specified in the call request 
packet. 


When more than one address applies to a DTE/DCE interface, the called line address 
modified notification facility may be used by the DTE in the clear request packet 
(when no call accepted packet has been transmitted) or the call accepted packet, when 
the called address is present in the packet and different from that specified in the 
incoming call packet. When this facility is received from the DTE: 


1. The DCE will clear the call if the called address is not one of those applying 
to the interface. 


2. If call redirection has taken place in the public data network, the DCE will 
replace the reason contained in the called line address modified notification 
facility with the reason reflecting the status of the originally called DTE; 
otherwise, the reason 1s passed transparently. 
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Note: The DIE should be aware that a modification of any part of the called DTE 
address field without notification by the called line address modified notification 
facility may cause the call to be cleared. 


| XI permits modification of the subaddress of the called DTE in the call accepted 
acket: without the need to use the called line address modified notification 
acility. 


The following reasons can be indicated with the use of the called line address 
modified notification facility in call connected or clear indication packets 
transmitted to the calling DTE: 

1 1. Call distribution within a Hunt Group (not applicable to XI) 
2. Call redirection due to originally called DTE out of order 
3. Call redirection due to originally called DTE busy 


4. Call redirection due to prior request from the originally called DTE for 
systematic call redirection 


1} 5. DTE originated (only in case of call transfer) 


In call accepted or clear request packets, the reason indicated in conjunction with 
the use of the called line address modified notification facility should be "DTE 
originated", 


included by the DTE in call accepted or clear request packets, and clears the call 
In this case, with cause "Invalid facility request" and diagnostic "Facility code not 

| allowed". XI delivers this facility to the calling DTE only if it is subscribed as 
an X.25 1984 compatible DTE. 


| XI does not accept the called line address modified notification facility to be 


6.27 CALL REDIRECTION NOTIFICATION 


Call redirection notification is a user facility used by the DCE in the incoming call 
acket to inform the alternate DTE that the call has been redirected, why the call 
@:: redirected, and the address of the originally called DTE. 


The following reasons can be indicated with the use of the call redirection 
notification facility (see 7.2.1 and 7.2.2.11): 


1. Call redirection due to originally called DTE out of order 
2. Call redirection due to originally called DTE busy 


3. Call redirection due to prior request from the originally called DTE for 
systematic call redirection. 


XI delivers the call redirection notification facility to the alternate DTE only if 
it is subscribed as an X.25 1984 compatible DTE, and if the basic (not SNBU) call 
redirection 1s being used. 


6.28 TRANSIT DELAY SELECTION AND INDICATION 


The transit delay selection and indication facility is not applicable in the XI 
environment. 


| 6.29 CALL TRANSFER 


Call Transfer is an optional user facility, specific to XI, which allows the 
originally called DTE to forward individual incoming virtual calls, after reception 
of the incoming call packet by this originally called DTE, or in data transfer phase. 
To use this facility, the originally called DTE must have subscribed the call transfer 
ubscription facility. 
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6.29.1 Call Transfer Subscription 


Call transfer subscription is an optional user facility, agreed for a period of time. 
This facility, if subscribed to, enables the DTE to request, by using the call 
transfer selection facility, that an individual call be transferred to an alternate 
DTE. The DTE can transfer the call: 


® at the time the individual call is presented to it by transmission of an incoming 
call packet 


e at any time in data transfer phase, after the incoming call packet has been 
accepted by a call accepted packet 


6.29.2 ‘Call Transfer Selection 


Call transfer selection is an optional user facility which may be used on a per 
virtual call basis. This facility may be requested by a DTE only if it has subscribed 
to the call transfer subscription. It is encoded as an X.25 facility. 


The call transfer selection facility may be used by the called DTE in the clear request 
packet, in direct response to an incoming call packet, or at any time, by the called 
DTE, in data transfer phase, to specify the alternate called DTE address to which the 
call is to be forwarded. If the call transfer selection facility is used in the clear 
request packet, then the DTE must also include any CCITT specified DTE facilities and 
user data to be sent to the alternate called DTE. Up to 16 octets of user data may 
be included in the clear request packet in this case. 


When requested for a given virtual call in response to an incoming call packet, the 
network transfers the call to the alternate DTE and does not respond to the calling 
DTE as a result of the clearing at the originally called DTE/DCE interface. The X.25 
facilities that are present in the incoming call packet transmitted to the alternate 
called DTE are those that would have been present in the incoming call packet if the 
call was a regular call from the calling DTE to the alternate DTE. The call 
redirection notification facility, with a specific reason, indicated in the call 
transfer selection reason, is delivered to the alternate DTE if it 18S subscribed as 
an X.25 1984 compatible DTE. The called line address modified notification facility, 
with the same specific reason, 15 delivered to the calling DTE if it is subscribed 
as an X.25 1984 compatible DTE. 


When requested for a given virtual call in data transfer phase, the network transfers 
the call to the alternate DTE and notifies the calling DTE as a result of the response 
of the alternate DTE to the incoming call packet it receives: 


e a clear request packet in basic format sent by the alternate DTE will result in 
a clear indication packet transmitted to the calling DTE, with a called line 


address modified notification facility included if the calling DTE is an X.25 1984 
compatible DTE. 


e a call accepted packet sent by the alternate DTE will result ina reset indication 
packet transmitted to the calling DTE. The cause is the reason of the transfer, 
the diagnostic is 00. 


The X.25 facilities that are present in the incoming call packet transmitted to the 
alternate called DTE are those that would have been present in the incoming call 
packet if the call was a regular call from the calling DTE to the alternate DTE. 


6.29.3 Call Redirection Notification 


The call redirection notification facility is included by the DCE tn the incoming call 
packet to inform the alternate DTE that the call has been transferred, and to indicate 
the address of the originally called DTE, if the alternate DTE 1s subscribed as an 
X.25 1984 compatible DTE. The reason indicated in this case is: 


e Call transfer by the originally called DTE 
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[| 6.29.4 Called Line Address Modified Notification 


The called line address modified notification facility is included by the DCE in the 
call connected or clear indication packet to inform the calling DTE that the call has 
een forwarded, if the calling DTE is subscribed as an X.25 1984 compatible DTE. The 
eason indicated in this case is: 


e Call transfer by the originally called DTE 


6.30 DIRECT CALL 


Direct call is an optional user facility, specific to XI, defined for further study 
in Recommendation X.2, agreed for a period of time. 


The principle of sucha facility consists in assigning to one or more than one logical 
channel of a DTE/DCE interface a complementary subscription parameter allowing the 
DCE to initiate a virtual call set-up procedure on selected logical channels with 
parameters defined at subscription time (mainly the address of the called DTE). 
virtual call set-up on such a logical channel is performed each time the logical 
channel is turned to state pl: This means that the virtual call will be set-up after 
the link level initialization and the restart procedure and each time the virtual call 
will be cleared either by the called DTE, by the DCE in case of network congestion, 
or by the DTE itself. 


When the virtual call is set-up, i.e. when the called DTE has replied to the incoming 
call packet by a call accepted packet, the DCE issues to the DTE a reset indication 
with a cause "remote DTE operational” and a specific XI diagnostic "direct call 
completed". If the virtual call cannot be set-up, the DCE will issue a reset 
indication with the cause and the diagnostic of the clear request. 


During the time the virtual call set-up is attempted, any data packet sent by the DTE 
will cause the DCE to reply with a reset indication packet, with the cause and the 
diagnostic of the most recent clearing procedure. If no clearing procedure has 
occurred, then the cause is "Network out of order” and the diagnostic "Direct call 
an progress", 


In the case where the virtual call set-up procedure fails, and independently of the 
cause of the failure (network congestion, called DTE busy or out of order,...), the 
DCE makes Nxl1 attempts with a gap of Txl seconds after the last clear. Nxl and JTxl 
are part of direct call parameters, but Txl will not be lower than a network parameter 
Tximin. 


These retries occur only if one of the following conditions 1s met 
e the clearing procedure 1s initiated by the network 


e the clearing procedure is initiated by the called DTE, and the direct call logical 
channel has been subscribed with the reconnection option 


A Direct Call logical channel appears to the DTE as a permanent virtual circuit on 
the primary end (the one which initializes the virtual call set-up), and as a switched 
virtual circuit at the other end. 
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7. FORMATS FOR FACILITY FIELDS AND REGISTRATION FIELDS 


7.1 GENERAL 


The facility field is present only when a DTE 18 using an optional user facility 


requiring some indication in the call request, incoming call, call accepted, call 
connected, clear request, clear _ indication, or DCE clear confirmation packet. 


The registration field is not used in the XI environment. 


The facility/registration field contains one or more facility/registration elements. 
The first octet of each facility/registration element contains a 
facility/registration code to indicate the facility or facilities 
requested/negotiated. 


The facility/registration codes are divided into four classes, by making use of bits 
8 and 7 of the facility/registration code field, in order to specify 
facility/registration parameters consisting of 1, 2, 3, or a variable number of 
octets. The general class coding of the facility/registration code field is shown 
in Table 26/X.25. 


TABLE 26/7X.25 


General Class Coding for Facilityv/Registration Code Fields 


Class A single octet parameter field 


Class B double octet parameter field 
Class C triple octet parameter field 
Class D variable length parameter field 


For class D the octet following the facility/registration code indicates the length, 
in octets, of the facility/registration parameter field. The facility/registration 


parameter field length is binary coded and bit 1 is the low order bit of this 
indicator. 


The formats for the four classes are shown in Figure 19/7X.25. 
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Class A Class B 
® Bits | Bits 


87654321 87654321 


0 0X X XK X X X 0O1xX xX XXX xX 


Facility/ Facility/ 
registration registration 
parameter field 


parameter field 


Class C Class D 
Bits | Bits 
87654321 87654321 


1 0X XX X X X 11XXXXXKX 


Facility/ Facility/ 

registration registration 
parameter field 

parameter length 


field Facility/ 
registration 
parameter field 


e& FIGURE 197X.25 


Facility/Registration Element General Format 


The facility/registration code field is binary coded and, without extension, provides 
for a maximum of 64 facility/registration codes for classes A, B and C and 63 
facility/registration codes for class D giving a total of 255 facility/registration 
codes. 


Facility/registration code 1L1111111 1s reserved for extension of the 
facility/registration code. The octet following this octet indicates an extended 
facility/registration code having the format A, B, C, and D as defined above. 
Repetition of facility/registration code 11111111 is permitted and additional 
extensions thus result. 


The coding of the facility/registration parameter field is dependent on the facility 
being requested/negotiated. 


A facility/registration code may be assigned to identify a number of specific 
facilities, each having a bit in the parameter field indicating facility 
requested/facility not requested. In this situation, the parameter field is binary 
encoded with each bit position relating to a specific facility. A 0 indicates that 
the facility related to the particular bit is not requested and ail indicates that 
the facility related to the particular bit is requested. Parameter bit positions not 
assigned to a specific facility are set to zero. If none of the facilities represented 
by the facility/registration code is requested for a virtual call or for online 
facility registration, the facility/registration code and its associated parameter 
field need not be present. 
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In addition to the facility/registration codes defined in 7, other codes may be used 
for: 


e Non X.25 facilities. XI does not offer non-X.25 facilities. The XI-specific call 
transfer selection facility is encoded as an X.25 facility. 


° CCITT-specified DTE facilities as described in Annex G of this Recommendation 
(call set-up, clear request and clear indication packets). 


CCITT specified DTE facilities can be used by DTEs. XI makes use of the extended 
address facilities for virtual calls established between a DTE attached to an XI 
network and a DTE attached to a PSDN connected with the XI network. 


Facility/registration markers, consisting of a single octet pair, are used to separate 
requests for X.25 facilities as defined in 6 and 7 from other categories as defined 
above, and, when several categories of facilities are simultaneously present, to 
separate these categories from each other. 


The first octet of the marker is a facility/registration code field and is set to zero. 
The second octet is a facility/registration parameter field. 


The facility/registration parameter field of a marker is set to zero when the marker . 


precedes requests for: | 
e Registration codes specific to the local network (registration packets) 


e Non-X.25 facilities provided by the network in case of intranetwork calls (call 
set-up packets) 


® Non-X.25 facilities provided by the network to which the calling DTE is 
connected, in case of internetwork calls (call set-up packets). 


If a DTE attached to XI issues a call request with a facility marker parameter set 
to all zeros, the call is cleared, with cause "invalid facility request" and 
diagnostic “facility code not allowed". 


The facility parameter field of a marker is set to all ones when the marker precedes 
requests for non-X.25 facilities provided by the network to which the called DTE is 
connected, in case of intranetwork calls (call set-up packets). 


The facility parameter field of a marker is set to 00001111 when the marker precedes 
requests for CCITI-specified DIE facilities. 


All networks will support the facility markers with a facility parameter field set 
to all ones or to 00001111. . 


DTEs should not use a facility marker with a facility parameter field set to all ones 
in case of intranetwork calls. However, if a DTE uses such a marker in an intranetwork 
call, the DCE is not obliged to clear the call, and the marker, with the corresponding 
facility requests, may be transmitted to the remote DTE. 


In this situation, XI does not clear the call, and the marker with the corresponding 
facility request is transmitted to the remote DTE. 


Facility/registration codes for X.25 facilities and for the other categories of 
facilities may be simultaneously present. However, requests for X.25 facilities must 
precede the other requests, and requests for CCITT-specified DTE facilities must 
follow the other requests. 

A call request issued by a DTE attached to an XI node may include a: 

e Request for X.25 facilities 


e Request for non-X.25 facilities provided by the network to which the called DTE 
1S connected. This may be the case when there is a GW-DTE with a PSDN. 


® Request for CCITT-specified DTE facilities. 

However, the maximum size of the last two categories of requests Cif any), including 
the separating marker between these two categories (Cif any), must be lower than or 
equal to 58 octets. 

The coding of CCITT-specified DTE facilities should comply with the description in 
Annex G. However, the DCE is not required to verify that compliance. If the network 


104 XI DTE/DCE Interface Description 


Se eee ete 


IBM Confidential 


verifies that compliance and finds an error, it may clear the call with the cause 
"Invalid facility request". The CCITT-specified DTE facilities are otherwise passed 
unchanged by public data networks between the two packet-mode DTEs. 


The only CCITT-defined DTE facilities which are checked by an XI network are the 
xtended address facilities, as described in 5.8. 


7.2 CODING OF FACILITY FIELD IN CALL SET-UP AND CLEARING PACKETS 


The coding of the facility code field and the format of the facility parameter field 
are the same in the various call set-up and clearing packets in which they are used. 


7.2.1 Coding of the Facility Code Fields 


Table 27/X.25 gives the coding of the facility code fields and the packet types in 
which they may be present. 


| The facilities which are supported by XI are: 


° flow control parameters negotiation (packet size, window size) 


| e closed user group selection (basic format) 


e closed user group with outgoing access selection (basic format) 


e reverse charging 


| 

| e called line address modified notification 
| ® call redirection notification 

| e call transfer selection 
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TABLE 277X.25 Cpart 1 of 2) 
Coding of the Facility Code Field 


Packet types in which it may be used Facility 


Facility Bits 
CalljInc.|Call Call |Clear|Clear|Clear 
Req. /|Call/|Accept.{|Conn.|Req. |Ind. [Confirm./|8 7 6 5 4 
—basic format 


Flow control x x x xX 
parameter 
negotiation 
—-packet size 
—window size 
Throughput x X xX x 
not supported by XI 
xX X 
—-extended format 
Closed user xX X 
group with 
outgoing access 
selection 
—basic format 
—-extended format 
xX 


negotiation 


Closed user 
group selection 


class 
Bilateral closed 


user group 
selection 


0 
0 
not supported by XI 


01000001 
Reverse chereinol x {x |_| | | | 
00000001 
Fast select xX x 
selection not supported by XI 


Network user Xx X 11009001410 
identification not supported by XI 


Charging 
information 

—requesting xX X 00060001 0 0 
service 

—receilving X xX 


Information 

-monetary unit 

-distance 

-segment count . 

-call duration not supported by XI 
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TABLE 277X.25 (part 2 of 2) 
Coding of the Facility Code Field 


Packet types in which it may be used 
RPOA selection 


DCE 
CalljiInc.|Call Call |Clearj|jClear|Clear 
Req. /|CalljAccept.|]Conn.|Req. |Ind. |Confirm. 
X 
—basic format 


—extended format not supported by XI 
Called line xX xX X x 0 
address modified 

notification (1) C1) 


Call redirection X 

notification 

Transit delay X 010010041 
11000011 


Facility 
Bits 
8765 4 


oe 


100 0 
100 0 
0001 


ol]ler 


0 0 
0 0 
0 0 


selection and 
indication 


not supported by XI 


Call transfer 
selection 


specific to XI 


ote: 


- Not supported by XI for these types of packet 


' 
; 
; 


Coding of the Facility Parameter Fields 


7.2.2.1 Flow Control Parameter Negotiation Facility 
7.2.2.1.1 Packet Size 


The packet size for the direction of transmission from the called DTE is indicated 
in bits 4, 3, 2, and 1 of the first octet of the facility parameter field. The packet 
size for the direction of transmission from the calling DTE is indicated in bits 4, 
3, 2, and 1 of the second octet. Bits 8, 7, 6, and 5 of each octet must be zero. 


The four bits indicating each packet size are binary coded and express the logarithm 
base 2 of the number of octets of the maximum packet size. 


Networks may offer values from 4 to 12, corresponding to packet sizes of 16, 32, 64, 
128, 256, 512, 1024, 2048, or 4096, or a contiguous subset of these values. All 
Administrations will provide a packet size of 128. 


| XI permits packet sizes of between 64 and 1024 octets. The network service provider 
1 can define more constraining values. 


7.2.2.1.2 Window Size 


The window size for the direction of transmission from the called DTE is indicated 

in bits 7 to 1 of the first octet of the facility parameter field. The window size 
for the direction of transmission from the calling DTE 1s indicated in bits 7 to 1 

of the second octet. Bit 8 of each octet must be zero. 


The bits indicating each window size are binary coded and express the size of the 
window. A value of zero is not allowed. 
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Window sizes of 8 to 127 are only valid if extended sequence numbering is used (see 
6.2). The ranges of contiguous values allowed by a network for calls with normal 
numbering and extended numbering are network dependent. All Administrations will 
provide a window size of 2. 

XI permits window sizes of between 1 and 7 (modulo 8) and between 1 and 15 (modulo 
128). The network service provider can define more constraining values. 

7.2.2.2 Throughput Class Negotiation Facility 


The Throughput class negotiation facility is not applicable in the XI environment. 


7.2.2.3 Closed User Group Selection Facility 

7.2.2.3.1 Basic Format 

The index to the closed user group selected for the virtual call is in the form of 
two decimal digits. Each digit 1s coded in a semi-octet in binary coded decimal with 
bit 5 being the low order bit of the first digit and bit 1 being the low order bit 
of the second digit. 


Indexes to the same closed user group at different DTE/DCE interfaces may be 
different. 


7.2.2.3.2 Extended Format 

The maximum number of closed user groups a DTE can subscribe to with XI is 100, thus 
the extended format is not permitted. 

7.2.2.% Closed User Group with Outgoing Access Selection Facility 

7.2.2.4.1 Basic Format 

The index to the closed user group selected for the virtual call is in the form of 
two decimal digits. Each digit is coded in a semi~octet in binary coded decimal with 
bit 5 being the low order bit of the first digit and bit 1 being the low order bit 


of the second digit. 


Indexes to the same closed user group at different DTE/DCE interfaces may be 
different. 


7.2.2.4%.2 Extended Format 

The maximum number of closed user groups a DTE can subscribe to with XI is 100, thus 
the extended format is not permitted. 

7.2.2.5 Bilateral Closed User Group Selection Facility 

The Bilateral closed user group selection facility is not applicable in the XI 
environment. : 

7.2.2.6 Reverse Charging and Fast Select Facilities 

The coding of the facility parameter field is: 


Bit 1 = 0 for reverse charging not requested 
Bit 1 = 1 for reverse charging requested. 


Note - Bits 6, 5, 4, 3, and 2 may be assigned to other facilities in the future; 
presently, they are set to 0. 


The fast select facility is not applicable in the XI environment. 
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7.2.2.7 Network User Identification Facility 


| The Network user identification facility is not applicable in the XI environment. 


2.2.8 Charging Information Facility 


| The Charging information facility is not applicable in the XI environment. 


7.2.2.9 RPOA Selection Facility 


| The RPOA selection facility is not applicable in the XI environment. 


7.2.2.10 Called Line Address Modified Notification Facility 


The coding of the facility parameter field for called line address modified 
notification is: 


Bits: 87654321 

000003111 Call distribution within a Hunt Group 
(see Note 1) 

00000001 Call redirection due to originally called DTE 
busy 

0000i1004d21 Call redirection due to originally called DTE out 
of order 

000031313141 Call redirection due to prior request from 


redirection 

DTE originated 

(see Note 1) 

131XXXXX X Call transfer by the originally called DTE 
(see Note 2) 


jue 
fo | 
< 
< 
< 


originally called DTE for systematic call 
| 


Note: 


| 
e ” supported by XI 

2 The Xs are those set by the originally called DTE in the call transfer selection 
| facility 


7.2.2-l1 Call Redirection Notification Facility 

The octet following the facility code field indicates the length, in octets, of the 
facility parameter field and has the value n + 2, where n is the number of octets 
necessary to hold the originally called DTE address. 


The first octet of the facility parameter field indicates the reason for the call 
redirection and has one of the following values: 


Bits: 87654321 
00 0 0 
000 0 


0 0 
0 0 


0 1 Originally called DTE busy 

1 1 Originally called DTE out of order 
06000114141 Systematic call redirection 

X X 


1 1X X xX X Call transfer by the originally called DTE 


(see Note 1) 


Note: 


1. The Xs are those set by the originally called DTE in the call transfer selection 
facility 
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The second octet indicates, in bits 4, 3, 2 and 1, the number of semi-octets in the 
originally called DTE address. This address length indicator is binary coded and bit 
1 is the low order bit. Bits 8, 7, 6 and 5 of this octet are set to zero. 

The following octets Cup to 8) contain the originally called DTE address, coded 
identically to the called DTE address field in the call request packet (see 5.2.1.3). 
7.2.2.12 Transit Delay Selection and Indication Facility 

The Transit delay selection and indication facility is not applicable in the XI 
environment. 

7.2.2.-13 Call Transfer Selection Facility 

The octet following the facility code indicates the length, in octets, of the facility 
parameter field and has the value nt2, where n is the number of octets necessary to 


hold the called address of the DTE to which the call is to be transferred. 


The first octet of the facility parameter field indicates the reason for the DTE 
transferring the call. The coding of this octet is: 


Bits: 87654321 
11XXXXX xX 


Note: Each X may be independently set to 0 or 1 by the called DTE and is’ passed 
transparently to the DTE to which the call is transferred. If bits 8 and 7 are not 
set to 1 by the called DTE, they are forced to this value by the DCE 


7.3. CODING OF THE REGISTRATION CODE FIELD OF REGISTRATION PACKETS 


The coding of the registration code field of registration packets is not applicable 
in the XI environment. 
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OEE RANGE OF LOGICAL CHANNELS USED FOR VIRTUAL CALLS AND PERMANENT VIRTUAL 


@' the case of a single logical channel DTE, logical channel 1 will be used. 


or each multiple logical channel DTE/DCE interface, a range of logical channels will 
be agreed upon with the Administration according to Figure A-1/X.25. 


LCN 
| Permanent virtual circuits and Direct calls 
LIC 
One way 
Incoming 
HIC 
LTC . 
| Two way Virtual calls 
HTC : 
LOC 
One way 
outgoing 
HOC 


4095 


LCN Logical channel number 
LIC Lowest tncoming channel 
HIC Highest incoming channel 
LTC Lowest two-way channel 


OC Lowest outgoing channel 


@:: Highest two-way channel 


OC Highest outgoing channel 


Logical channels 1 to LIC-1l: range of logical channels which may be assigned to 
permanent virtual circuits. ) 

Logical channels LIC to HIC: range of logical channels which are assigned to one-way 
incoming logical channels for virtual calls (see 6.8). 

Logical channels LTC to HTC: range of logical channels which are assigned to two-way 
logical channels for virtual calls. 

Logical channels LOC to HOC: range of logical channels which are assigned to one-way 
outgoing logical channels for virtual calls (see 6.7). 

Logical channels HIC#1 to LTC-1, HTC#1 to LOC-1, and HOC#1 to 4095 are non-assigned 
logical channels. 


FIGURE A-1/X.25 


Note 1 - The reference to the number of logical channels is made according to a set 
of contiguous numbers from 0 Clowest) to 4095 Chighest) using 12 bits made up of the 
4 bits of the logical channel group number (see 5.1.2) and the 8 bits of the logical 
channel number (see 5.1.3). The numbering 1s binary coded using bit positions 4 
through 1 of octet 1 followed by bit positions 8 through 1 of octet 2 with bit 1 of 
octet 2 as the low order bit. 


Note 2 - All logical channel boundaries are agreed with the Administration for a 
period of time. 


For XI, the assigned logical channels within a logical channel group must be 
consecutive (no gaps) and must start from the first value in this group, i.e., from 
1 in group O and 256xN in group N (where N < 16). A particular range of logical 


channels can extend over more than one logical channel group. 
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Note 3 - In order to avoid frequent rearrangement of logical channels, not all logical 
channels within the range for permanent virtual circuits are necessarily assigned. 


With XI, not all logical channels within the range for permanent virtual circuits are 
necessarily assigned at subscription time. Moreover, a logical channel assigned to 
a permanent virtual circuit can be active or not depending on whether the permanent 
virtual circuit has been activated or not by an appropriate operator command. 


A logical channel which is assigned to a permanent virtual circuit 1s to be assigned 
with a complementary status (specific to XI) indicating whether the logical channel 
1S primary or secondary. This status does not modify the procedure nor the state 
diagrams at the DTE/DCE interface, but is used by the XI node to activate or 
re-activate the permanent virtual circuit after a network failure. 


Direct Call logical channels are assigned within the range of PVCs. 


The maximum number of logical channels and their ranges are necessarily part of the 
configuration of the XI node. However, the assignment of logical channels can be 


modified through appropriate operator commands that enable or disable logical 
channels. 


Note 4 - In the absence of permanent virtual circuits, logical channel 1 is available 
for LIC. In the absence of permanent virtual circuits and one-way incoming logical 
channels, logical channel 1 is available for LTC. In the absence of permanent virtual 
circuits, one-way incoming logical channels and two-way logical channels, logical 
channel 1 is available for LOC. 


Note 5 - The DCE search algorithm for a logical channel for a new incoming call will 
be to use the lowest logical channel in the ready state in the range of LIC to HIC 
an TC to HTC. 


Note 6 - In order to minimize the risk of call collision, the DTE search algorithm 
1s suggested to start with the highest numbered logical channel in the ready state. 
The DTE could start with the two-way logical channel or one-way outgoing logical 
channel ranges. 
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ANNEX B. PACKET LEVEL DTE/DCE INTERFACE STATE DIAGRAMS 


B.1 SYMBOL DEFINITION OF THE STATE DIAGRAMS 


Transition 
> 


State number 


State name 


( DCE »< Responsibility for the transition 


( DTE ) 
> CPacket < Packet transferred 
Transition type) 
V 
Note 1 - Each state is represented by a box wherein the state name and number are 
indicated. 
Note 2 - Each state transition 1s represented by an arrow. The responsibility for 


the transition (CDTE or DCE) and the packet that has been transferred is’ indicated 
beside that arrow. 


B.2 ORDER DEFINITION OF THE STATE DIAGRAMS 


@-- the sake of clarity, the normal procedure at the interface is described in a number 

of small state diagrams. In order to describe the normal procedure fully, it is 
necessary to allocate a priority to the different figures and to relate a higher order 
diagram with a lower one. This has been done by the following means: 


° The figures are arranged in order of priority with Figure B-1/7X.25 (Crestart) 
having the highest priority and subsequent figures having lower priority. 
Priority means that when a packet belonging to a higher order diagram is 
transferred, that diagram 1s applicable and the lower order one is not. 


° The relation with a state ina lower order diagram is given by including that state 
inside an ellipse tn the higher order diagram. 
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1 


es 
DTE!] Packet level ready |DCE 


Restart Restart 
Ready 
request pl or dl indication 
(see Note 1) 
Restart confirmation Restart confirmation 
or restart indication or restart request 
V DCE DTE V 


r2 r3 
DTE restart DCE restart 


request indication 
DTE| A A I DCE 
VY | | V 
— > <_< 
Restart request Restart indication 


(see Note 2) 


Note 1 — State pl for virtual calls or state dl for permanent virtual circuits. 


Note 2 — This transition may take place after time-out 1T10. 


FIGURE B-1/X.25 


Diagram of States for the Transfer of Restart Packets 


For XI, the DCE state r2 is transient, as the DCE will immediately send a restart 
confirmation just after a restart request has been received. Moreover, the DCE will 
send a restart indication each time the link level is set up or reset. 


114 XI DTE/DCE Interface Description 


Qo 
2 DCE 


p 
DTE waiting 


Incoming call 


Call request 
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Incoming call 
V 


DTE p3 


DCE waiting 
Call request 


V 
p5 
Call collision 


DCE 


Call connected 


DCE 


Call connected 


a) Call set-up phase 


Clear requestiAny state 


1 DTE 
>|flow control |< 


Call accepted 


p4¢ Data transfer 


Clear tndication 


V V 

@. DCE DTE DCE DTE Call 
connected p6 p7 accepted 
(see Note 1) DTE clear DCE clear (see Note 2) or 
or Incoming request indication] < Call request 


call 
(see Note 5) 


DCE clear confirmation 
or clear indication 


b) Call clearing phase 


Note 1 — This transition 
Note 2 — This transition 
Note 3 — This transition 
Note 4 — This transition 
Waiting (p3). 

Note 5 — This transition 


Ea eS 


Waiting (Cp2). 


Clear (see Note 4) 
Indication 


(see Note 3) 
DTE 
< 


Clear 
request 


DCE 
> 
DTE clear confirmation 


or clear request 


is possible only if the previous state was DTE Waiting (p2). 
is possible only if the previous state was DCE Waiting (p3). 


may take place after time-out 1T13. 


is possible only if the previous state was Ready (pl) or DCE 


is possible only if the previous state was ready (pl) or DTE 


FIGURE B-2/7X.25 


Diagram of States for the Transfer of Call Set-up and Call 
Clearing Packets within the Packet Level Ready (rl) State 
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For XI, the DCE state p6 is transient, as the DCE will immediately send a clear 
confirmation just after the reception of a clear request from the DTE (the clear 
confirmation has local sitgnificance). 


DTE dl DCE @ 
Reset!i Flow controljReset } 


request indication 


Reset request or DTE 
reset confirmation 


Reset indication or 
DCE reset confirmation 


DTE DCE 


d2 d3 
DTE reset DCE reset 
request Indication] < 


Reset 
request 


Reset 
indication 
(see Note) 


Note —- This transition may take place after time-out T12. 


FIGURE B-3/7X.25 


Diagram of States for the Transfer of Reset Packets 
within the Data Transfer (p4) State 


For XI, the DCE state d2 is transient, as the DCE will immediately send a reset 
confirmation just after the reception of a reset request from the DTE (the reset 
confirmation has local significance). 
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ANNEX C. ACTIONS TAKEN BY THE DCE ON RECEIPT OF PACKETS 


IN _A_GIVEN STATE OF THE PACKET LEVEL DTE/DCE INTERFACE AS PERCEIVED BY THE DCE 


C.1 INTRODUCTION 


This annex specifies the actions taken by the DCE on receipt of packets in a given 
state of the packet level DTE/DCE interface as perceived by the DCE. 


It is presented as a succession of chained tables. 
The following rules are valid for all these tables: 


1. There may be more than one error associated with a packet. The network will stop 


normal processing of a packet when an error 18S encountered. Thus only one 
diagnostic code is associated with an error indication by the DCE . The order 
of packet decoding and checking on networks is not standardized é 


2. For those networks which are octet aligned, the detection of a non-integral number 
of octets may be made at the frame or packet level. In this annex, only those 
networks which are octet aligned and detect the non-integral number of octets at 
the packet level are concerned with the considerations about octet alignment. 


| XI networks are octet aligned and the detection of packets not including an 
| integral number of octets 1s performed at link level. 
3. In each table, the actions taken by the DCE are indicated in the following way: 


e DISCARD: the DCE discards the received packet and takes no subsequent action 
as a direct result of receiving that packet; the DCE remains in the same 


©} state. 


e DIAG ® x: the DCE discards the received packet and, for networks which 
implement the diagnostic packet, transmits to the DTE a diagnostic packet 
containing the diagnostic # x. The state of the interface 15s not changed. 

| XI networks make use of the diagnostic packet. 
e NORMAL or ERROR: the corresponding action is specified after each table. 


4. Annex E gives a list of the diagnostic codes which may be used. 


TABLE C1/X.25 


Special Cases 


including link level valid I-frame containing no packet 


Any packet with correct GFI and assigned logical 
channel, or with correct GFI and bits 1 to 4 of octet il 
and bits 1 to 8 of octet 2 equal to 0 


Csee Table 
C—-2/X.25) 
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TABLE C2/X.25 


Action Taken bv the DCE on Receipt of Packets ina Given State 
of the Packet Level DTE/DCE Interface as Perceived by the 


DCE: Restart and Registration Procedure 


State of the interface as 
perceived by the DCE ——2 


Packet from the DTE a 


Restart request NORMAL (r2) DISCARD NORMAL (rl) 


DTE restart confirmation ERROR (r3) |ERROR Cr3) |NORMAL (ri) 
# 17 #18 
Data, interrupt, call set-up and See Table ERROR (r3) DISCARD 
clearing, flow control or reset C—-3/X.25 or % #18 
C-4/7X.25 
(see Note) 
Restart request, DTE restart See Table ERROR (r3) DISCARD 
# 41 
3 


confirmation or registration C-3/X.25 or 
request with bits 1 to 4 of octet 1)C-4/X.25 
ERROR (r3) DISCARD 
# 38 
ERROR (r3) DISCARD 
# 33 


or bits 1 to 8 of octet 2 unequal (see Note) 
DIAG # 36 DIAG # 36 DIAG # 36 


DTE restart}|/DCE restart 
level ready|request indication 


r3 


r2 


to zero 


See Table 
C-3/X.25 or 
C-47X.25 

(see Note) 


Packet having a packet type 
identifier which is shorter than 1 
octet 


See Table 
C-3/X.25 or 
C-4/7X.25 

(see Note) 


Packet having a packet type 
identifier which is undefined or 
not supported by the DCE (that is, 
reject or registration packet) 


Packet other than restart request, 
DTE restart confirmation and 
registration request with bits 1 to 
4 of octet 1 and bits 1 to 8 of 
octet 2 equal to zero 


Registration request NORMAL Cri1){]NORMAL Cr2)/NORMAL Cr3) 


Note — Table C-3/X.25 for logical channels assigned to virtual calls, Table C~-4/7X.25 
for logical channels assigned to permanent virtual circuits. 


If XI receives a registration packet in state rl, it handles it as an ERROR (r3) # 
33, 1.e., issues a restart indication, cause "local procedure error” and diagnostic 
"unidentifiable packet". 


ERROR (r3) # x: 


The DCE discards the received packet, indicates a restarting by transmitting to the 
DTE a restart indication packet, with the cause "Local procedure error™ and the 
diagnostic # x, and enters state r3. If connected through a virtual call, the distant 
DTE 18 also informed of the restarting by a clear _ indication packet, with the cause 
"Remote procedure error™ (same diagnostic). In the case of a permanent virtual 
circuit, the distant DTE will be informed by a reset indication packet, with the cause 
"Remote procedure error”™ (same diagnostic). 


NORMAL (Crl): 


Provided none of the following error conditions has occurred, the action taken by the 
ee ee the procedure as defined in 3 and 6.1, and the DTE/DCE interface enters 
state rl: 
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a. If a restart request packet or DTE restart confirmation packet received in 
state r3, or a registration request packet received in state r2 or r3, exceeds 
the maximum permitted length, is too short or is not octet aligned (see rule 
2 in the introduction of this annex), the DCE will invoke the ERROR # 39, #& 
38 or # 82 procedure, respectively. 


‘ Registration request packets are not applicable in the XI environment. 
{ XI networks invoke the ERROR # 81 procedure, if the restarting cause field 
| is not "DTE originated” in the restart request packet received in state r3. 


b. If a restart request or a registration request packet received in state rl 
exceeds the maximum permitted length, 1s too short or is not octet aligned 
(see rule 2 in the introduction of this annex), the DCE shall invoke the DIAG 
# 39, # 38, or # 82 procedure, respectively. 


| XI networks invoke the DIAG # 81 procedure, if the restarting cause field is 
| not "DTE originated" in the restart request packet received in state rl. 


c. If a registration request packet is received from the DTE when the on-line 
facility registration facility is supported by the DCE but not subscribed by 
the DTE, the DCE shall transmit to the DTE a registration confirmation packet 
with the cause "Local procedure error™, the diagnostic # 42, and no 
registration field. 


If a registration request packet modifying one or more of the facilities which can 
take effect only when all logical channels used for virtual calls are in state pl (see 
Annex F) is received when it is possible to make the modification, the DCE shall 
transmit aorestart indication packet with the cause "Registration/cancellation 
confirmed™ and diagnostic # 0 and enter state r3, if there is one or more logical 
channels assigned to permanent virtual circuits. This action ensures that the 
permanent virtual circuits are reset so that all of the negotiated facilities can take 
effect properly. 
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TABLE C3/7X.25 


Action Taken by the DCE on Receipt of Packets in a Given 
State of the Packet Level DTE/DCE Interface as Perceived b 
the DCE: Call Set-up and Clearing on Logical Channel 
Assigned to Virtual Call (See Note 1) 


State of the inter 
face as perceived 
by the DCE ———>]|Ready DCE clear 
pl indication 


Packet level ready rl 


Packet from the 
DTE with logical | 
channel assigned 

to virtual call V 


Call request NORMAL] ERROR | NORMAL ERROR ERROR ERROR DISCARD 
(p2) (p7) (p5) (p7) (p7) (p7) 
# 21 # 23 # 24 # 25 

Call accepted ERROR ERROR |NORMAL ERROR ERROR ERROR DISCARD 
(p7) (p7) (p4) (p7) (p7) (p7) 
# 20 # 21 % 23 # 24 # 25 

Clear request NORMALINORMAL |NORMAL NORMAL NORMAL DISCARD NORMAL 

(p6) (p6) (p6) (p6) (p6) Cpl) 


DTE clear ERROR ERROR ERROR ERROR ERROR ERROR NORMAL 
confirmation (p7) Cp7) (p7) Cp7) (p7) Cp7) (pl) 
$§ 20 # 21 ¥ 22 # 23 # 24 # 25 


Note 3) {Note 2) 


Data, interrupt, ERROR ERROR ERROR /See ERROR ERROR DISCARD 
reset, or flow C(p7) (p7) (p7) Table (p7) (p7) 
control # 20 # 21 # 22 C-4/X.25 # 24 # 25 


ERROR ERROR ERROR /[See ERROR ERROR DISCARD 
(p7) (p7) (p7) Table (p7) (p7) 
# 41 # 41 # 41 C-4/7X.25 #41 #41 


Packets having a ERROR ERROR ERROR {See ERROR ERROR DISCARD 
packet type iden-— C(p7) C(p7) Table (p7) C(p7) 

tifier which jis % 38 # 38 # 38 C—-47X.25 # 38 # 38 

shorter than one 

octet 


ERROR ERROR DISCARD 
(p7) (p7) 
# 33 # 33 


Restart request, 
DTE restart confi- 
rmation, or regis— 
stration request 
with bits 1 to 4 
of octet 1 or bits 
1 to 8 of octet 2 
unequal to zero 


~ 
G 

wd 
ww 


Packets having a ERROR ERROR ERROR 
packet type iden- [| (p7) (p7) C(p7) 
tifier which is # 33 —# 33 # 33 
undefined or not 

supported by the 

DCE Ci.e., reject 

or registration 

packet) 
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Note 1 - On permanent virtual circuit, only state P4 exists and the DCE takes no action 


except those specified in Table C-4/X.25. 


Note 2 - This state does not exist in the case of an outgoing one-way logical channel 


e* perceived by the DTE). 


ote 3 - This state does not exist in the case of an incoming one-way logical channel 


(as perceived by the DTE). 
ERROR (p7) # x: 


The DCE discards the received packet, indicates a clearing by transmitting to the DTE 
a clear indication packet, with the cause "Local procedure error" and the diagnostic 
# x, and enters state p7. If connected through a virtual call, the distant DTE is 
also informed of the clearing by a clear indication packet, with the cause "Remote 
procedure error" (same diagnostic). 


NORMAL (pl): 


Provided none of the following error conditions has occurred, the action taken by the 
DCE follows the procedures as defined in 4 and the DTE/DCE interface enters state pl. 
In all the cases specified hereunder, the DCE will transmit to the DTE a clear 
indication with the appropriate cause and diagnostic, and enter state p/7. If 
connected through a virtual call, the distant DTE is also informed of the clearing 
by a clear indication packet with the cause "Remote procedure error™ (same 
diagnostic). 


a) Call request packet 


Specific 

diagnostics 

(see Note 3 
Error condition of Annex E) 


1 Packet not octet aligned (see [Local procedure error 
rule 2 in the introduction of 
this annex) 


2 Incoming one-way logical Local procedure error 


channel Cas perceived by the 
DTE) 


3 Address contains a non-BCD #67, 68 
digit 


4 Invalid calling DTE address Local procedure error % 68 
(see Note) 
5 Invalid called DTE address Local procedure error 
# 67 


(see Note) or Not obtainable 
Note - Possible reasons for invalid address include: 
= Prefix digit no supported 
a National address smaller than national address format permits 
= National address larger than national address format permits 
a DNIC less than four digits, etc. 
In the case of XI, invalid addresses are addresses which do not comply with the rules 


given in 5.8 or which do not comply with the addressing scheme established by the 
network service provider. 
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Specific 
diagnostics 
(see Note 3 
Error condition Cause of Annex E) 
6 Value of the facility length Local procedure error # 69 
field greater than 109 
7 No combination of facilities Local procedure error 
could equal facility length 
8 Facility length larger than Local procedure error 
remainder of packet 


9 Facility code not allowed Invalid facility request 


10 Facility value not allowed or /iInvalid facility request 
invalid 

11 Invalid network user Invalid facility request 
identification 


12 Network user identification Local procedure error # 76 
facility expected by the DCE 
and not provided by the DTE 


¥ 38 
# 66 
13 Facility values conflicts (for|Invalid facility request ¥ 66 
example, a particular 
combination not supported) 
as 


14 CCITT specified DTE facility Invalid facility request 
code or parameter not allowed 
or invalid 


16 Address length larger than Local procedure error 
remainder of packet 


17 Call user data larger than 16 |Local procedure error 
or 128 tn case of fast select 
facility 


am 
18 Class coding of the facility Local procedure error az 


corresponding to a length of 
parameter larger than 
remainder of packet 
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If the virtual call cannot be established by the network, the DCE should use a call 
progress signal and diagnostic code among the following: 


Specific 

diagnostics 

(see Note 3 
Error condition Cause of Annex E) 


24 Reverse charging rejected Reverse charging 
acceptance not subscribed 

25 Fast select rejected | Fast select acceptance 
not subscribed 


26 Called DTE out of order Out of order 
# greater 
than 127 


29 RPOA out of order RPOA out of order 


30 The remote DTE/DCE interface 
or the transit network does 
not support a function or a 
facility requested 


Incompatible destination 


Note — Precise definition of error condition 30 necessitates further 
study and should take into account the possible non-sSupport of the 
virtual call service Conly permanent virtual circuit) by the 
destination DTE. 


31 Procedure error at the remote 
DTE/DCE interface 


(see 2. and 
3. below 
and Annex 


D) 


Remote procedure error 


32 Temporary network congestion 
or fault condition within the 
network 


Network congestion %¥0, # 122 


# greater 
than 127 
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Cause 


Local procedure error 


b) Call accepted packet 


Specific 
diagnostics 


(see Note 3 


Error condition 


of Annex E) 
1 Packet not octet aligned (see 
rule 2 in the introduction of 


# 82 
this annex) 
2 Address contains a non-BCD Local procedure error # 67, 
digit 
3 Invalid calling DTE address Local procedure error 
(see Note under 1.) 
4 Invalid called DTE address Local procedure error 
(see Note under 1.) 


5 Value of the facility length Local procedure error 
field greater than 109 

6 No combination of facilities Local procedure error 
could equal facility length 

7 Facility length larger than Local procedure error 
remainder of packet 


8 Facility code not allowed Invalid facility request 


9 Facility value not allowed or jInvalid facility request 
invalid 

10 Invalid network user Invalid facility request 
identification 


11 Network user identification hak 


Local procedure error 
facility expected by the DCE 
and not provided by the DTE 


12 Facility values conflicts (for|[Invalid facility request 
example, a particular 
combination not supported) 


13 Address length larger than Local procedure error 
remainder of packet 


14 Called user data larger than Local procedure error 
128 Cif fast select facility 
requested) 


15 Called user data present Cif Local procedure error 
fast select facility not 
requested) 


16 Class coding of the facility Local procedure error 
corresponding to a length of 


parameter field larger than 
remainder of packet 


18 The tincoming call packet Local procedure error # 42 
indicated fast select with 
restriction on response 

19 DTE facility code or parameter|Invalid facility request 
not allowed or invalid 
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Some networks may invoke the ERROR # 74 procedure if the address length fields are 
not equal to 0 in the call accepted packet, except when the called line address 
modified notification facility is present in the facility field. 


| The behaviour of an XI network regarding addresses is given in 5.8. 


@ Clear request packet 
ee 


Local procedure error 


Specific 
diagnostics 
(see Note 3 


Error condition 


of Annex E) 
1 Packet not octet aligned (see 
rule 2 in the introduction of 


# 82 
this annex) 


3 Packet length incorrectly Local procedure error % 39 
larger than 5 octets 


4 Calling DTE address length Local procedure error 
field not set to zero (at any 
time); called DTE address 
length field not set to zero | 
except when the called line 
address modified notification 
facility is present in 
clearing a call in state p3 


5 Invalid called DTE address Local procedure error 
when the called line address 
modified notification facility 
is present in clearing a call 
seers p3 Csee Note under 
1. 


6 Value of the facility length Local procedure error 
field greater than 109 


7 Clear user data larger than Local procedure error 
128 Cif fast select facility 
requested) 


8 Clear user data present (Cif Local procedure error 


fast select facility not 
requested) 


9 No combination of facilities Local procedure error #%# 69 
could equal facility length 

10 Facility length larger than Local procedure error % 38 
remainder of packet 


ll Facility code not allowed Invalid facility request 


12 Facility value not allowed or j|Invalid facility request 
invalid 


13 Class coding of the facility Local procedure error 
corresponding to a parameter 


field length larger than 
remainder of packet 


| XI networks invoke the ERROR # 81 procedure if the clearing cause field is not "DTE 
| originated" in the clear request packet. 
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d) DTE clear confirmation packet 


Specific © 


diagnostics 
(see Note 3 
Error condition of Annex E) 


1 Packet not octet aligned (see |lLocal procedure error 
rule 2 in the introduction of 
this annex) 


2 Packet length greater than 3 Local procedure error # 39 
octets 


TABLE C-4/X.25 


Action Taken by the DCE on Receipt of Packets ina Given State 
of the Packet Level DTE/DCE Interface as Perceived b 
the DCE: Transfer (Flow Control and Reset) on Assigned 


Logical Channels 


State of the interface as Data transfer p4 
perceived by the DCE —> 


DTE reset DCE reset 
request indication 


Packet from the DTE with | 
assigned logical channel 


V di d2 d3 
Restart request NORMAL (d2) DISCARD NORMAL (dl) 


DTE reset confirmation ERROR (€d3) [TERROR (d3) |NORMAL (Cdl) 
% 27 # 28 
Data, interrupt, or flow control NORMAL Cdl) ]/ ERROR (d3) DISCARD 


¥ 28 
Restart request, DTE restart ERROR (€d3) {ERROR (Cd3) DISCARD 
confirmation or registration & 41 # 41 
request with bits 1 to 4 of octet 1 
or bits 1 to 8 of octet 2 unequal 
to zero 7 
Packet having a packet type ERROR (€d3) |ERROR (Cd3) DISCARD 
tdentifier which is shorter than 1 F 38 % 38 
octet 
ERROR (d3) |ERROR (d3) DISCARD 
# 33 # 33 
reject or registration packet) 
Invalid packet type on a permanent |ERROR (€d3) {ERROR (d3) DISCARD 
virtual circuit # 35 # 35 
|TReject packet not subscribed ERROR ERROR (d3) DISCARD 
# # 37 


Packet having a packet type 
identifier which 1s undefined or 
not supported by the DCE (that 15s, 


126 XI DTE/DCE Interface Description 


IBM Confidential 


ERROR (d3) # x: 


The DCE discards the received packet, indicates a reset by transmitting to the DTE a 


reset 


indication packet, with the cause "Local procedure error" and the diagnostic 


xX» and enters state d3. The distant DTE is also informed of the reset by a reset 
ndication packet, with the cause "Remote procedure error” (same diagnostic). 


NORMAL (dl): 


Provided none of the following error conditions or special situations has occurred, 
the actions taken by the DCE follow the procedure as defined in 4 


a) 


b) 


c) 


d) 


e) 


>) 


If the packet exceeds the maximum permitted length, is too short, is not 
octet aligned (see rule 2 in the introduction of this annex), the DCE 
Will invoke the ERROR # 39, # 38, # 82 procedure, respectively. 


XI networks invoke the ERROR # 81 procedure if the resetting cause 
field in a reset request packet does not have the value "DTE originated”. 


XI networks invoke the ERROR # 83 procedure, if the Q@ bit is not set to the 
same value within a complete packet sequence. 


If the PCS) or PCR) received is not valid, the DCE will invoke the ERROR #? 1 
or # 2 procedure respectively. 


The DCE will consider the receipt of a DIE interrupt confirmation packet 
which does not correspond to a yet unconfirmed DCE interrupt packet as an 
error and will invoke the ERROR # 43 procedure. The DCE will consider a DTE 
interrupt packet received before a previous DTE interrupt packet has 

been confirmed as an error, and will invoke the ERROR # 44 procedure. 


If the network has a temporary inability to handle data traffic for a 
permanent virtual circuit (see 4.2), and if the packet is a data, interrupt, 
flow control or reset request packet received in state dl, the DCE shall 
transmit to the DTE a reset indication packet with the cause "Network out of 
order" and enter state d3 (data, interrupt or flow control, packet) or 

dil (reset request packet). 
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ANNEX D. PACKET LEVEL DCE TIME-OUTS AND DTE TIME-LIMITS 


D.1 DCE TIME-OUTS 


Under certain circumstances this Recommendation requires the DTE to respond to a 
packet issued from the DCE within a stated maximum time. 


Table D-1/X.25 covers these circumstances and the actions that the DCE will initiate 
upon the expiration of that time. 


The time-out values used by the DCE will never be less than those indicated in Table 
D-1/X.25. 


XI makes use of the time-out values indicated in Table D-1/X.25. These values are 
defined by the network service provider 


In table D-1/X.25, it is indicated that under certain cases of non-response from the 
DTE (case of permanent virtual circuit), the DCE may issue remote procedure error 
condition at the remote DTE/DCE interface; that is not the case for XI. However, if 
the remote DTE tries to send data, interrupt, or flow control packets while a 
retransmission procedure is performed at the local DTE/DCE interface, then the remote 
DCE will issue a remote procedure error condition at each attempt from the remote DTE. 


D.2 DTE TIME-LIMITS 


Under certain circumstances, this Recommendation requires the DCE to respond to a 
packet from the DTE within a stated maximum time. Table D-2/X.25 gives these maximum 
times. The actual DCE response times should be well within the specified time-limits. 
The rare situation where a time-limit ts exceeded should only occur when there is a 
fault condition. 


To facilitate recovery from such fault conditions, the DTE may incorporate timers. 
The time-limits given in Table D-2/X.25 are the lower limits of the times a DTE should 
allow for proper operation. A time-limit longer than the values shown may be used. 
Sard pelea on possible DTE actions upon expiration of the time-limits are given in 
Table D-2/7X.25. 


Note - A DTE may use a time shorter than the value given for T21 in Table D-2/X.25. 
This may be appropriate when the DTE knows the normal response time of the called DTE 
to an incoming call. In this case, the timer should account for the normal maximum 
response time of the called DTE and the estimated maximum call set-up time. 


Note ~ XI makes use of the diagnostic packet each time this possibility is quoted in 
Table D-1/7X.25. 
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TABLE D-17X.25 (CPart 1 of 2) 
DCE Time-outs (CFirst Time) 


Time—- |Time—-|Started/|State of|Normally 
out out when the terminated 
number |value logical |when 


Actions to be taken the first time 
the time-out expires 


DCE remains in 
r3, sitgnals a 
restart indica-— 
tion Clocal 
procedure 

error # 52) 
again, and 
restarts time- 
out 1T10 


channel 


T10 DCE DCE leaves 
issues the r3 state 
(that is, 
the restart 
1 confirmation 
or restart 
request 15 


received) 


For permanent 
virtual circuits, 
DCE may enter the 
d3 state signal- 
ing a reset indi- 
cation Cremote 
procedure error 

# 52) 


T11 DCE leaves DCE enters the DCE enters the p7 
the p3 stateip7 state signal-|state signaling a 
(that is, ing a clear clear indication 
the call indication Cremote procedure 
accepted; Clocal procedurelerror # 49) 
clear error # 49) 
request, or 
call request 
is received) 

T12 DCE leaves DCE remains in DCE may enter the 
the d3 state/|d3, signals a d3 state signal- 
(that is, reset indicattonjing a reset indi-— 
the reset Clocal procedure|/cation (Cremote 
confirmation{ferror # 51) procedure error 
or reset again, and # 51) 
request is restarts time- 
received) out T12 

T13 DCE leaves DCE remains tn 


the p/7 state 
Cthat is, 
the clear 
confirmation 
or clear 
request 15 
received) 


XI timer 
specificilexpires 


p7, signals a 
clear indication 
Clocal procedure 
error # 50) 
again, and 
restarts time- 
out 1713 


DCE on primary 
side sends a 
call request 
packet on the 
DC—-type logical 
channel 
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TABLE D-1/X.25 (Part 2 of 2) 
DCE Timeouts (Second Time) 


Actions to be taken the second 
time the time-out expires 


DCE enters the 
rl state and may 
issue a diagnos— 
tic packet 


State ofiNormally 
the terminated 
logical |jwhen 


Time— |Time—|Started 
out out when 
number | value 
channel 


10 DCE 
issues 
a 
restart 
indica— 
tion 
11 180 s{DCE 
issues 
T12 


DCE leaves 
the r3 state 
(that is, 
the restart 
confirmation 
or restart 
request is 
received) 


For permanent 
virtual circuits, 
DCE may enter the 
d3 state signal- 
ing a reset indi- 
tion Cremote pro- 
cedure error 


DCE leaves 
the p3 state 
(that is, 
the call 


an inco 
ming 
call accepted, 
clear 
request, or 
call request 


is received) 


r3 

d3 DCE leaves 
the d3 state 
(that is, 
the reset 
confirmation 
or reset 
request 15s 
received) 

p7 DCE leaves 
received) 

XI timer 

specificjexpires 
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For virtual 
calls, DCE enters 
the p7 state 
signaling a clear 
indication 
Cremote procedure 
error # 51). =For 
permanent virtual 
circuits, DCE may 
enter the d3 
state signaling 

a reset indica— 
tion Cremote 
procedure error 

# 51) 


For virtual 
calls, DCE 
enters the p7 
state signaling 
a clear indica-— 
tion Clocal 
procedure error 
#51). #=For 
permanent 
virtual circuits 
DCE enters the 
dl state and may 
issue a diagnos— 
tic packet 

C# 51) 


DCE enters the 
pl state and 
may 1ssue a 
diagnostic 
packet (# 50) 


the p7 
state (that 
1S> the 
clear con- 
firmation 
or clear 
request 15s 


DCE on primary 
side sends a 
call request 
packet on the 
DC-type logical 
channel 
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TABLE D-2/7X.25 
DTE Time-limits 


Started 
when 


State of!|Normally 

the terminated 
logical |when 
channel 


Preferred action to be taken 
when time-limit expires 


DTE 
1s5sues 
a 
restart 
request 


DTE leaves the 
r2 state (that 
1S> the 
restart confi- 
rmation or 
restart indi- 
cation 15 
received) 


To retransmit the restart 
request (see Note 1) 


DTE leaves the 
p2 state Cthat 
is, the call 
connected, 
clear indica— 
tion or inco- 
ming call is 
received) 


To transmit a clear request 


DTE leaves the 
d2 state (that 
1s, the reset 
confirmation 
or reset indi- 
cation 15 
received) 


For virtual calls, to retransmit 
the reset request or to transmit 
a clear request. For permanent 
virtual call circuits, to retra- 
nsmit the reset request (see 
Note 2) 


T23 180 DTE 
1ssues 
a clear 
request 


DTE leaves the 
P6 state (that 
is, the clear 
confirmation 
or clear indi-— 
cation 15s 
received) 


To transmit the clear request 
(see Note 2) 


300 DTE 
1ssues 


May retransmit the registration 
request, but should at some 
point recognize that the on-line 
facility registration facility 
1s not offered 


DTE receives 

the registra-— 
tion confirma-— 
tion or a dia- 
gnostic packet 


reaquest 


Z 
| 


Note 1 - After unsuccessful retries, recovery decisions should be taken at higher 
levels. 
Note 2 - After unsuccessful retries, the logical channel should be considered out of 


order. The restart procedure should only be invoked for recovery if reinitialization 


of all logical channels is acceptable. 


Note 3 - The DTE timers T2646 through T27 have been assigned by ISO in the specification 
of the packet level for X.25 DTEs. To avoid ambiguity and confusion, the time-out 


number has therefore been assigned T28. 
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ANNEX E. CODING OF X.25 NETWORK GENERATED DIAGNOSTIC FIELDS 


IN CLEAR, RESET AND RESTART INDICATION, REGISTRATION CONFIRMATION AND DIAGNOSTIC 
PACKETS 


Some of the diagnostics described here are not generated by an XI network. Some of 
them can be received by DTEs attached to an XI node only when the XI network is 
connected to a PSDN through the GWN-DTE function. 


In principle, when there is no ambiguity about the cause of the clear, reset, or 
restart, XI avoids using generic codes. 


Some XI specific diagnostics are added to the CCITT list when no relevant code is 


available. These codes are chosen from the value 128, upwards, as required by the 
Recommendation. 
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TABLE E-1/7X%.25 (part 1 of 3) 
(See Notes 1, 2, and 3) 


8 


5 4 3 


No additional information 
Invalid P(S) 
Invalid PCR) 


Packet type invalid 
For state rl 
For state r2 
For state r3 
For state pl 
For state p2 
For state p3 
For state p4 
For state p5 
For state p6 
For state p/7 
For state dl 
For state d2 
For state 


Packet not allowed 
Unidentifiable packet 

Call on one-way logical channel 

Invalid packet type on a permanent 
virtual circuit 

Packet on unassigned logical channel 
Reject not subscribed to 

Packet too short 

Packet too long 

Invalid general format identifier 
Restart or registration packet with non- 
zero in bits 1 to 4@ of octet 1, or bits 
1 to 8 of octet 2 

Packet type not compatible with facility 
Unauthorized interrupt confirmation 
Unauthorized interrupt 

Unauthorized reject 


6 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
1 
1 
1 
1 
1 
1 
1 
1 
1 


qQooococe Ooo on ] Seoaeaeoeaeaooaoaaoaoooeo co | ooo ~~ 


21 
0 0 
01 
1 0 
1 1 
00 
01 
1 0 
11 
0 0 
01 
1 0 
11 
0 0 
01 
1 0 
11 
0 0 
01 
11 
0 0 
01 
1 0 
11 
0 0 
01 
1 0 
1 1 
0 0 


SPEDOTDQO PAQOD!lo!l_eamnd—d—deqgagaaaQcaaGO!]lalaoo 
D2OQQDQDGDO 000 | & |] BPR RRR Pe PRP ee eee | Oo | OOO 
MOaDOoDoQ G00] &] KR RR rR QOD DOCOGQ0!]H | Coo 


CO re be kt tt © QOoeo - MRPrR OOCoOFP rR eR Oooo -— ooo 


expired 
For incoming call 

For clear indication 
For reset indication 
restart indication 


Qloaanca00;{,a!lcoo0o0o 
~~ 1 Oorreaoaad!]e | COFPFSO 
mm | ORORO!] Fe | RK OKFOF 


Qloaoooo0o!aloovoo0o 
ed 
i meee | O 1 OCDO0E 
~ 1 QQ0000 [& | RR Hee 
Hl RP OQO00 le | KH OOO 
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TABLE E-1/X.25 (Cpart 2 of 3) 


(See Notes l, 


Diagnostics 


Miscellaneous 


2, and 3) 


Call set-up, call clearing or 
registration problem 


Facility/registration code not allowed 
Facility parameter not allowed 
Invalid called address 

Invalid calling address 

Invalid facility/registration length 
Incoming call barred 

No logical channel available 

Call collision 

Duplicate facility requested 

Non zero address length 

Non zero facility length 

Facility not provided when expected 
Invalid CCITT—-specified DTE facility 


Improper cause code from DTE 
Not aligned octet 
Inconsistent Q bit setting 


Not assigned 
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International problem 


Remote network problem 
International protocol problem 
International link out of order 
International link busy 

Transit network facility problem 
Remote network facility problem 
International routing problem 
Temporary routing problem 
Unknown called DNIC 
Maintenance action (see Note 4) 
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87654321 


De ee ee ee ee ee ee Nd ol ol ool ol dl el el do 
| peri | ri he | O | OOOO] OG] ©2MPMOQODTOAOOCOCOCOOQO00oO 
poe | eee pepper ieee | OL Ole [| eR ee | Oo | OODDQOTTOCDAQ0QC9000So 
mM Re mMOaDaoarmgoaoooco |e! ale | COO O] F&F | KR RRR RrOORaOOOOoOeo 
~~ | OOOR KH RP MaGDOO!]leH 1 Ol He | COOO] eH | RK RK OOO OFRFKR RFR OOO °o 
m | POOR MOOR rRP OO le 1 Ole | KR kK OOo] ee | COrFRrF OOF rFrOOrFr OO 
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TABLE E-1/X.25 (Cpart 3 of 3) 
(See Notes 1, 2, and 3) 


87654321 


Reserved for network specific diagnostic 
Information 
subscription error 
permanent virtual circuit not activated 
remote access link event/status: 
: —link level not initiated or 
restart indication pending 
—-line or modems failure 
—-DISC from the DTE 
—disconnected by operator 
—-SABM/UA exchange completed 
—-DM sent by the DCE 
previous reset not confirmed 
call transfer in progress 
direct call in progress 
direct call set-up completed 
invalid called address extension 
user facilities length larger than 58 
invalid redirection address 
call transfer not supported on calling 
side 


ee ee ee ee 
TOQVDDDDQDDODAQSDTO 2 20EOQ 
COKDDQACAOCAOCDOCCO 2 F200 
MOaORDRDOOQ®MQQCQCCOD 20 O00 
OK HHH eRe OOOO FOF F200 
ORK ERM ODOOORFFRFE ©G 2OOo 
OFF OOFFPOOFRFOO -- FOO 
COFMOKFOFROrFPOrROFO -F& OF°2a 


lijiliiii 


Note 1 - Not all diagnostic codes need apply to a specific network, but those used 
Ce as coded in the table. 


ote 2 - A given diagnostic need not apply to all packet types (Ci.e., reset indication, 
clear indication, restart indication, registration confirmation, and diagnostic 
packets). 


Note 3 - The first diagnostic in each grouping is a generic diagnostic and can be used 
in place of the more specific diagnostics within the grouping. The decimal 0 
diagnostic code can be used in situations where no additional information is 
available. 


Note 4 - This diagnostic may also apply to a maintenance action within a national 
network. 
| Note 5 - XI specific diagnostic codes between 131 and 136 are issued associated with 


the cause "out of order™, to give more tnformation to the remote DTE. 
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ANNEX F. APPLICABILITY OF THE ONLINE FACILITY REGISTRATION FACILITY TO OTHER 
FACILITIES 


The applicability of the online facility registration facility to other facilities © 
is not applicable in the XI environment. 
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ANNEX G. CCITT-SPECIFIED DTE FACILITIES TO SUPPORT THE OSI NETWORK SERVICE 


G.1 INTRODUCTION 


>. facilities described in this Annex are intended to support end-to-end signalling 
required by the OSI Network service. They follow the CCITT-specified DTE facility 
marker defined in 7.1. These facilities are passed unchanged between the two packet 
mode DTEs involved. 


XI accepts any of the CCITT-specified DTE Facilities, and deliver them unchanged to 
the called DTE. 


In general, an XI network does not act upon the content of DTE facilities, except for 
extended addressing facilities, when a virtual call is set up between a DTE attached 
to a PSDN anda DTE attached to an XI network. In this case, the called address 
extension facility needs to be in one of the two specific formats described in 5.8 
(XI address formats) 


Procedures for use of these facilities by DTEs require definition by international 
user bodies. Subsequent provision of X.25 facilities to be acted on by public data 
networks 1s for further study. Coding of the facilities in this Annex is defined here 
in order to facilitate a consistent facility coding scheme in such future evolution. 


G.2 CODING OF THE FACILITY CODE FIELDS 


Table G-1/X.25 gives the coding of the facility code field for each CCITT-specified 
DTE facility and the packet types in which they may be present. These facilities are 
conveyed after the CCITT-~specified DTE facility marker. 


TABLE G-1/X.25 


@ Coding of the Facility Code Field 


Packet types which may be 
used in the facility 
Facility CalljInc.{Call Call |Clear|Clear 
req. {|{calllaccept.|conn.jind. req. 


negotiation: 
minimum throughput class] X xX 

end-to-end transit delayj| X xX xX xX 
Expedited data xX xX X X 
negotiation 


Facility code 


Bits 
87654321 


110031011 
11001001 


Quality of service 
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G.3 CODING OF THE FACILITY PARAMETER FIELDS 


G.3.1 Calling Address Extension Facility 


The octet following the facility code field indicates the length in octets of the 


facility parameter field and has a value of n + l, 


where n may be a maxtmum of 16 


octets in order to hold the calling address extension. 


The first octet of the facility parameter field indicates, 
1, the number of semi-octets (up to 32) in the calling address extension. 
length indicator is binary coded and bit 1 


octet are set 
The following 


Each digit of 
5 or 1 is the 


Starting from 
octets of the 


higher order digit is coded in bits 8, 


When necessary, the facility parameter field shall be rounded up to an 
of octets by inserting zeros in bits 4, 


in bits 6, 5, 4, 3, 2, and 
This address 
1s the low-order bit. Bits 8 and7 of this 


to zero. 
octets (up to 16) contain the calling address extension. 


an address is coded ina semi-~octet 
low-order bit of the digit. 


in binary coded decimal, where bit 


the high-order digit, the address is coded in octet 2 and consecutive 
facility parameter field with two digits per octet. In each octet, the 
7, 6 and 5. 


integral number 


3, 2 and 1 of the last octet of the field. 


G.3.2 Called Address Extension Facility 


The octet following the facility code field indicates the length in octets of the 


facility parameter field and has a value of n + l, 


where n may be a maximum of 16 


octets in order to hold the called address extension. 


The first octet of the facility parameter field indicates, 
1, the number of semi-octets Cup to 32) 
length tndicator is binary coded and bit Il 


octet are set 
The following 


Each digit of 
5 or 1 1s the 


Starting from 
octets of the 


higher order digit 


In bits 6, 
in the called address extension. 
1s the low-order bit. 


5, 4, 3; 2 and 
This address 


Bits 8 and 7 of this 
to zero. 


octets (up to 16) contain the called address extension. 


an address is coded in a semi-octet in binary coded decimal, where bit 
low-order bit of the digit. 


the high-order digit, the address is coded in octet 2 and consecutive 
facility parameter field with two digits per octet. In each octet, the 
1s coded in bits 8, 7, 6 and 5. 


When necessary, the facility parameter field shall be rounded up to an integral number 


of octets by inserting zeros in bits 4, 


3, 2 and 1 of the last octet of the field. 


G.3.3 Quality of Service Negotiation Facilities 


G.3.3.1 Minimum Throughput Class Facility 


The minimum throughput class for the direction of data transmission from the calling 


DTE is indicated in bits 4, 3, 2 andl. 
of data transmission from the called DTE is indicated in bits 8, 


The four bits 


The minimum throughput class for the direction 
7» 6 and 5. 


indicating each throughput class are binary coded and correspond to 


throughput classes as indicated in Table 28/X.25. 


G.3.3.2 End-to-end Transit Delay Facility 


The octet following the facility code field indicates the length in octets of the 


facility parameter field and has the value 2; 
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4 or 6. 
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The first and second octets of the facility parameter field contain the cumulative 
transit delay. The third and fourth octets are optional and, when present, contain 
the requested end-to-end transit delay. The fifth and sixth octets are optional and, 
when present, contain the maximum acceptable end-to-end transit delay. If the third 
and fourth octets are present, then the fifth and sixth octets are also optional. 
@:: fifth and sixth octets, when present, contain the maximum acceptable end-to-end 


ransit delay. The optional octets are not present in call accepted and call 
connected packets. 


Transit delay is expressed in milliseconds and 1s binary-coded, with bit 8 of the 

first of a pair of octets being the high-order bit and bit 1 of the second of a pair 
of octets being the low-order bit. The value of all ones for cumulative transit delay 
indicates that the cumulative transit delay is unknown or exceeds 65 534 milliseconds. 


G.3.4 Expedited Data Negotiation Facilit 


The coding of the facility parameter field is: 


Bit 1 = 0 for no use of expedited data 
Bit 1 = 1 for use of expedited data. 


Note - Bits 8, 7, 6, 5, 4, 3 and 2 may be assigned to other facilities in the future; 
presently, they are set to zero. 
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ANNEX H. SUMMARY OF DIFFERENCES BETHEEN THE 1980 AND THE 1984 VERSIONS OF X.25 


The following charts depict differences between the 1980 and 1984 versions of CCITT 
Recommendation X.25. | 


Legend: 
B — Base Function 
— Limited 


Optional Function 
Unspeci fied 
Not Applicable 


PHYSICAL LEVEL 


Ref. 
# Function 


1. X.21 Interface x x 
2. X.21-Bis Interface ¥ 
3. V-series Interface xX pon | 


x See other applicable 1984 CCITT Recommendations for possible incompatibilities. @ 


%X This tnterface is required for X.32. X.32 is a new recommendation 
for switched access to an X.25 network. 
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B. LINK LEVEL 
Ref. 
# Function 


1. Phase-Synchronization 
2. Initialization-Phase 
3. Disconnection—-Phase 


4. DCE-Timer-T3 
CIdle Channel Ttme-out) 


5. I-frame-Rejyection-Recovery 


6. DTE-Data-Integrity 
Responsibility 


Version 
"80 *84 


DM-Response-Contention- 
Resolution 


12. U-Command-Contention- 
Resolution 
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Summary of Differences between the 1980 and the 1984 Versions of X.25 
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C. PACKET LEVEL 
Ref. 
# Function 


1. Datagram-Services 


2. Extended-Interrupt- 
User-Data 


[S. SinglecPackew/freme |v 
[e- actet-Packet-Alionment | U_ 
[6 network-Error-Resctiona | U_ 
(7. Exmanded-Diagneatie-coden | 0 
(a. Expanded-DTE-couse-Codes |W 
(2. expandea-Packet-sizes—[ W_ 
10. Expanded-Facility-Lensth |W 

— 


Version 


11. Expanded-Facilities-Field 
12. Extended Clear-Request and 
Clear-Indication Formats 
13. Extended Clear-Confirmation 
Formats 


D. NEW OPTIONAL USER FACILITIES 


Ref. 
# Function 


1. On-Line-Facility- 
Registration 


Version 


2. Local-Charging-Prevention 
3. Network-User-Identification 
4 


. Charging-Information 


6. Call-Redirection Ew ee 
7. Called-Line-Address- 
Modi fied-Notification 


8. Call-Redirection—- 
Notification 


9. Transit-Delay-Selection- 
and-Indication 
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E. OPTIONAL USER FACILITY EXTENSIONS 


Ref. 
# Function 


1. CUG Selection 


2. CUG with Outgoing Access 
~ Selection 
3. Absence of both CUG 
Selection-Facilities 


4. No Preferred CUG 


5. Bilateral CUG Selection 
6. Extended RPOA Selection 
7. Essential Fast Select 


CCITT-SPECIFIED DTE FACILITIES 


Ref. 
# Function 
1 


- K'OF'-Facility-Marker pn | oo | 
2. Address-Extension Fon | oo | 
3. Minimum-Thru-put Class | on | oo | 


Version 


4. Transit-Delay 


5. Expedited-Data-Negotiation 


An 
Summary of Differences between the 1980 and the 1984 Versions of X.25 
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LINK LEVEL 


The references in parenthesis itn this section refer to items in the relevant CCITT 
recommendation. 


1. 


144 


Disconnected Phase 


1984 - (2.4.4.1, 2nd paragraph) Introduces the concept of a 'Phase 
Synchronization’ function whereby either the DTE or the DCE may transmit a DISC 
command, prior to initiation of the link set-up procedure, to ensure that the DTE 
and DCE are in the same (Disconnected) phase. 


1980 - Unspecified (subject to interpretation). 
Link Set-Up 


1984 - (2.4.4.2, 5th paragraph) Introduces a ‘Initialization Phase’ wherein all 
frames except SABM/SABME and DISC command, or UA and DM responses, received 
following initiation of the link set-up procedure (for example, transmission or 
receipt of an SABM/SABME command) and prior to completion of that link set-up 
procedure (for example, receipt or transmission of an acknowledging UA) are 
explicitly ignored by the DTE or the DCE unless or until link set-up is aborted 
by the transfer of a DM response. 


1980 - Explicitly defines only a "Disconnected Phase’ and an ‘Information Transfer 
Phase’ Csubject to interpretation). 


Link Disconnection 

1984 - (2.4.4.3, 4th paragraph) Introduces a "Disconnection Phase’ wherein all 
frames except SABM/SABME commands, or UA and DM responses received following the 
Inittation of the link disconnection procedure (for example, transmission or 
receipt of a DISC command) and prior to completion of the disconnection procedure 
(for example, receipt or transmission of an acknowledging UA or DM response) are 
explicitly ignored by the DTE or the DCE. 


1980 - Explicitly defines only a "Disconnected Phase’ and an "Information Transfer 
Phase’ (subject to interpretation). 


DCE-Timer T3 CIdle Channel Time-out) 

1984 - (2.3.5.5) Defines a period T3 that DCEs, after detecting the 'Idle Channel 
State’ condition, shall wait for detection of a return to "Active Channel State’ 
before signalling the condition to a higher level. 

1980 - Not Applicable. 


I-frame Rejection Recovery 


1984 - (2.4.5.9, 8th paragraph) Specifically prohibits duplicate I-frame 
re-transmissions within the same numbering cycle. 


1980 - Ignores duplicate I-frame retransmissions. 

Data Integrity Responsibility 

1984 - (2.3.4.5, 4th paragraph and 2.3.4.6, 2nd paragraph) Explicitly place 
responsibility for recovery from the possible loss of I-frame contents with a 
higher level. 

1980 - Undefined. 

Octet Frame Alignment 


1984 - €2.3.5.3, 2nd paragraph) Explicitly allows octet aligned networks to ignore 
non-octet aligned frames as invalid. 


1980 - Undefined. 
Frame Sequencing 


1984 - €2.4%) Incorporates an optional extended mode wherein frame sequencing is 
performed modulo 128. 
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1980 - Limits frames sequencing to modulo 8. 


Multilink 


1984 - €2.5) Incorporates optional procedures for control of multiple access links 
at a DTE/DCE interface. 


1980 - Limits DTE/DCE interfaces to single access link. 
Restricted Flag Sequences 


1984 -€2.2.2, 2nd sentence) Restricts sequences of multiple flags transmitted to 
complete 8-bit flag sequences. 


1980 - Allows shared 00-bit flag sequences. 

DM-Response Contention Situation 

1984 - (2.4.4.7) Explicitly places responsibility for resolution with the DTE. 
1980 - Undefined. 

U-Command Contention Situation 

1984 - €2.4.4.5.1) Explicitly places responsibility for resolution with the DCE. 
1980 - Undefined. 
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H.2 PACKET LEVEL 


Datagram Service 

1984 - Undefined. 

1980 - (5.0) Additional optional service. 

Expanded Interrupt User Data 

1984 - (5.3.2.1 and Figure 7) Expands the length of the user data field in 
interrupt packets to a maximum of 32 octets (usage may be established by 
negotiation). 

1980 - Limited to exactly 1 octet. 

Single Packet/Frame 


1984 - (3.0, 2nd paragraph) Explicitly limits the information field of I-frames 
to a single packet. 


1980 - Unresolved. 

Octet Packet Alignment 

1984 - €3.0, 3rd paragraph and Note 1) User data field must be octet aligned. 
1980 - Unresolved. 

D-bit Negotiation Procedure 

1984 - (4.3.3) Assumes full network support of the D bit procedures. 

1980 - Interim. 

Network Error Reactions 

1984 - (3, 4, and 5 and Annex D) Clarifies DTE and DCE responses on time outs. 
1980 - Unresolved. 

Expanded Diagnostic Codes 

1984 - CAnnex E) Adds new diagnostic codes for ‘Packet Not Allowed’, ‘Call Set-up, 
Call Clearing or Registration Problems’, ‘Miscellaneous’ and ‘International 
Problems’. 

1980 - Undefined. 

DTE/DCE Cause Code 


1984 - €5.2.3.1.1, 2nd paragraph; Table 18; 5.4.3.1, 2nd paragraph; Table 19; and 
5.5.1.1, 2nd paragraph) Assign values X'00' and optionally > X'80'" for DTEs. 


1980 - Limited to X'00° for DTE's. 
User Data Field 


1984 - (4.3.2, 2nd paragraph) Accommodates new optional maximum user data field 
lengths of 2048 and 46096 octets. 


1980 - Maximum User Data Field length limited to 1024 octets. 
Factlity Length Field 


1984 - (5.2.1, Figure 2; 5.2.2, Figure 3; 5.2.3, Figure 4; and 5.2.4, Figure 5) 
Expanded to 8-bits with a maximum value of 109. 


1980 - Restricted to 6-bits with a maximum value of 63. 
Facilities field 


In call-request, incoming-call, call-accepted and call-connected packets: 
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1984 - (5.2.1.6, 3rd paragraph and 5.2.2.1.5, 3rd paragraph) Length extended to 
accommodate up to 109 octets. 


1980 - Length Limited to 63 octets. 
Address and facility lengths 
In Clear Request and Clear Indication: 


1984 - (5.2.3.2 and Figure 4) Defines an optional extended format for use in 
conjunction with one or more optional user facilities. 


1980 - Limited to X'00' and allowed only when clear user data field is included 
In the clear request or clear indication packet. 


Clear Confirmation 


1984 - €5.2.4% and Figure 5) Defines an optional extended format to accommodate 
clear user data for use only with the charging information facility. 


1980 - Defines only a basic packet format with no user data field. 
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Online Facility Registration 
1984 - (5.7.2, 6.1, Figure 17) 
1980 - Not defined. 

Local Charging Prevention 
1984 - (6.20). 

1980 - Not defined. 

Network User Identification 
1984 - (6.21). 

1980 - Not defined. 

Charging Information 

1984 - (6.22). 

1980 - Not defined. 

Hunt Group 

1984 - (6.24). 

1980 - Not defined. 

Call Redirection 

1984 - (6.25). 

1980 - Not defined. 
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Called Line Address Modified Notification 


1984 - (6.26). 
1980 


Not defined. 

Call Redirection Notification 
1984 - (6.27). 

1980 - Not defined. 


Transit Delay Selection and Indication 


1984 - (6.28). 
1980 - Not defined. 
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OPTIONAL USER FACILITY EXTENSIONS 


Closed User Group Selection 
C7.2.2.3.2) - Extended Format 

1984 - (6.14.6). 

1980 - Not explicitly defined. 

CUG with Outgoing Access Selection 
(7.2.2.4.2) - Extended Format 

1984 ~- (6.14.7). 

1980 - Not explicitly defined. 

Absence of Both CUG Selection Facilities 

1984 - (6.14.8). 

1980 - Not defined. 

No Preferential CUG 


1984 - (6.14.2) Allows networks to offer the capability of choosing whether or 


not to have a preferential CUG. 
1980 - Not allowed. 

Bilateral CUG Selection 

1984 - (6.15.3). 

1980 - Not explicitly defined. 
RPOA Selection Facility Extensions 
(7.2.2.9.2) - Extended Format 
1984 - (6.23, 3rd paragraph). 

1980 - Not defined. 


Essential Fast Select Facility 


1984 - (6.16) Assumes universal availability of the facility. 


1980 - Optional availability. 


Optional User Facility Extensions 
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H.5 CCITT-SPECIFIED DTE FACILITIES 


Facility Marker = X'0F' 

1984 (7.1, 15th paragraph and G.1). 
1980 - Not defined. 

Address Extension 

1984 - (G.3.1 and G.3.2) - Option. 
1980 ~- Not defined. 

Minimum Throughput Class Negotiation 
1984 - (6.3.3.1) - Option. 

1980 - Not defined. 

Transit Delay Negotiation 

1984 - (6.3.3.2) - Option. 

1980 - Not defined. 

Expedited Data Negotiation 

1984 - (6.3.4) - Option. 

1980 - Not defined. 
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APPENDIX I. EXAMPLES OF LINK LEVEL TRANSMITTED BIT PATTERNS BY THE DCE AND THE DTE 


ill exist the physical link for some of the unnumbered frames. It 1s included for 
he purpose of bettering the understanding of the transparency mechanism and the frame 
check sequence implementation. 


@ii appendix is provided for explanatory purposes and indicates the bit patterns that 


I.1 


The following are examples of the bit patterns that will be transmitted for some 
unnumbered frames: 


Example 1:  SABM command frame with address A, P = 1 


ja bit transmitted Last bit transmitted 
V V 
0111 1110 1100 0000 1111 1€0°)100 1101 1010 0011 0111 0111 1110 
Flag Address=-A SABM (P = 1) Frame check sequence Flag 


Example 2: UA response frame with address B, F = 1 


(ls bit transmitted Last bit transmitted 
V V 
O111 1110 1000 0000 1100 1110 1100 0001 1110 1010 0111 1110 
Flag Address=B UA CF = 1) Frame check sequence Flag 
I.2 


The following are examples of the bit patterns that should be transmitted by a DTE 
for some unnumbered frames: 


xample 1:  SABM command frame with address B, P = 1 


First bit transmitted Last bit transmitted 
y } | 
0111 1110 1000 0000 1111 0¢€0%)100 1101 0111 11¢007)11 1011 O111 1110 
Flag Address=B SABM (P = 1) Frame check sequence Flag 


Example 2: UA response frame with address A, F = 1 


First bit transmitted Last bit transmitted 
’ \ 
0111 1110 1100 0000 1100 1110 1100 1100 0010 0110 0111 1110 
Flag Address=-A UA (CF = 1) Frame check sequence Flag 


3 zero inserted for transparency 
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° PART TWO 


REVISED RECOMMENDATION X.32 
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3. DTE SERVICE DESCRIPTIONS 


3.1 DTE SERVICE ATTRIBUTES 


3.1.1 DTE Identity 


The "DTE identity” attribute, when provided, defines the identity of the DTE. 


3.1.2 DTE Identification Method 


[| Not applicable in the XI environment. 


3.1.3 Registered Address 


The "registered address” is a number assigned by the PSPDN to the DTE to be used to 
represent the DTE identity in the address fields of call setup packets, when a DTE 
identity is directly agreed to (see 2.3). 


When a registered address is provided, the "registered address" attribute defines the 
number allocated by the PSPDN to the DTE. 


| With XI, the registered address is a number (or a set of numbers if subaddressing is 
| used) valid in the XI addressing scheme. 


3.1.3.1 Registered Address Not Provided 


When a registered address is not provided, the value given in the address field of a 
all set-up packet is discussed below. 


In the case of dial-in-by-the-DTE, when the DTE makes a call request, the contents 
of the calling address field in the corresponding Incoming Call packet are as shown 
in Table 1/7X.32. 


TABLE 17X.32 


Calling address field content when a registered address 
is not provided 


Calling DTE Calling address 
field content 


Nonidentified - see Temporary number 
2eaveut from the PSDN 
numbering plan 
(Note 3) 


Note 3 


If the temporary number jis used, the called DTE must be made aware that the contents 
of the calling address field 1s not a DTE address. The means to convey this information 
are for further study. Pending the results of such a study, this option may be used 
nationally, but such a temporary number shall not be carried on international 
interconnection. 


With XI, the dialing DTE is temporarily assigned the address of the port it has dialed. 
he format of the calling address field is the same as in the case of leased access. 
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2.6 DIAL-IN-BY-THE-DTE AND DIAL-OUT-BY-THE PSPDN OPERATION 


All PSPDNs conforming to this Recommendation shall provide dial-in-by-the-DTE 
operation. Provision of dial-out-by-the-PSDN operation is optional. 


XI provides dial-out-by-the PSDN for back-up (SNBU) mode of operation. 


2.7 DTE SERVICE REQUIREMENT 


To provide a switched access service to DTEs, without introducing additional 
procedures, all PSPDNs conforming to this Recommendation shall offer the nonidentified 
DTE service and/or support use of the provided-by-the-PSN DTE identification method. 


XI offers the nonidentified DTE service with SNAF mode of operation. 


2.8 DUPLEX AND HALF-DUPLEX OPERATION 


If CSPDN access is used, the transmission facility 1s duplex. If PSTN access is used, 
the transmission facility operation is duplex, or optionally, some networks may also 
provide for half-duplex operation. The additional procedures necessary for 
half-duplex operation are described in 5.6. 


XI only supports PSTN access, in duplex mode. 


2.9 IDENTIFICATION PROTOCOL 


Not applicable in the XI environment. 
2.10 NEGOTIATION OF VALUES 6 


Presently, DCE parameters are set to specific values according to the DTE profile as 
outlined in 2.3 and 3. 
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Some networks may offer service to identified DTEs, that is, to DTEs for which an 
implicit or explicit DIE identity is provided to the DCE via one of the methods 
specified in 2.4%. Different types of service are defined for use in different 
situations. The network may offer one or more of these services. 


his applies to the SNBU mode of operation of XI, though none of the identification 
ethods described in 2.4 applies to XI. 


The three types of service defined in this Recommendation are called DTE services. 
One is a service for unidentified DTEs. The other two are services for identified 
DTEs. The three DTE services are: 

a. WNonidentified, 

b. Identified, and 

c. Customized. 
2.3.2.1 Service for Unidentified DTEs The service offered to unidentified DTEs is 
called "nonidentified" DTE service and is detailed in 3.3. This DTE service may be 


offered as part of dial-in-by-the-DTE or dial-out-by-the-PSPDN operation or both. 


For XI, this service applies only to dial-in-by-the-DTE operation (CSNAF mode of 
operation). 


For a dial-in-by-the-DTE operation, the switched access path shall not be disconnected 
for a period of time (T14) even in, the absence of any virtual calls. This allows 
users a period of time to reestablish a virtual call. See 7.5. 


For dial-in-by-the-DTE operation, the PSPDN may Limit the number of unsuccessful 
attempts to establish a virtual call. 


This limitation is not implemented by XI. 


When a DTE uses the SNAF service, it 1s not required to use any optional procedures. 


2.3.c.e¢ services for Identified DTEsS The services offered to identified DTEs provide 


} set of capabilities/facilities different from and/or enhanced beyond the 


onidentified DTE service. 


Identified 


XI does not offer the “*identified"™ DTE service. 


Customized 


The PSPDN may offer the "customized" DTE service in which the DTE identity has been 
explicitly agreed to with the Administration, a registered address has been allocated 
and the other attributes are set according to the DTE profile which has been 
customized for the DTE according to the capabilities supported by the network as 
permitted within the specification given in 3.5. The effect is that this DTE 1s 
billable, has an X.121 address registered with the PSPDN, and is provided a service 
tailored in many aspects to its requirements. This DTE service may be offered as part 
of dial-itn-by-the-DTE or dial-out-by-the-PSPDN operation or both. 


XI offers this service only for dial-out-by-the DTE (CSNBU) mode of operation. 


2.% DTE IDENTIFICATION METHODS 


2-5 DCE IDENTIFICATION METHODS 


Not applicable in the XI environment. 
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of call set-up packets. This number is called a "registered address” and is defined 
in 3.1.3. 


2.3.1 Service Attributes 


"Attributes" are defined to describe each aspect of switched access service. However, 
the values of the attributes do not necessarily include all capabilities offered to 
PSPDN users that access the PSPDN via a leased line. The attributes are: 
1. DTE identity, 

DTE identification method, 


- Registered address, 


- Registered PSN number, 


2 
3 
4 
5. X.25 subscription set, 
6. Logical channels assignment, 

7. Dial-out-by-the-PSPDN availability, 

8. Modem selection, 

9. Temporary location, 

10. Secure dial-back, 

11. DCE identity presentation, and 

12. Link level address assignment. 

For each DTE service, each attribute either: 
1. Is not provided or 

2. Is provided and either: 


a. 1s set to a default value specified by the network (Network Default) or 


b. is set to a value selected by the user from a set of values provided by the 
network (CUser Selectable). 


Note: A network may define a default value for the attribute. 


A "DTE profile” is the set of values of the Network Default and User Selectable 
attributes that have been selected for a particular DTE identity. 


Note: The DTE profile need not be stored in the PSPDN. 

Some networks may allow a subscriber to arrange for more than one DTE profile to meet 

different requirements for switched access service. Each DTE profile is independent. 

A "DTE profile designator" is used to differentiate the multiple profiles of the DTE. 
| For SNBU operations, each DTE has its own DTE profile, which is the one used for normal 

operations on the leased line. For SNAF operation, each XI network may offer more than 


one DTE profile; each DTE profile is a function of the PSTN number to be used by the 
| DTE for access to one of the DCE ports of the XI network. 


2.3.c DTE Services 


Some networks may offer service to unidentified DTEs; that is, to DTEs for which no 
identification is provided to the DCE. 


| This applies to the SNAF mode of operation of XI. 
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number from a numbering plan, identification of the DTE service and authority, 
validity dates and period, public keys used for authentication, etc. 


| In SNBU, the DTE identity is agreed upon with the network service provider. The DTE 
| identity is composed of a number (XI home DTE address) in the XI addressing scheme. 


he characteristics of the service which a DTE obtains via dial-in-by-the-DTE or 
dial-out-by-the-PSPDN access depend upon whether the PSPDN considers the DTE 
identified for each particular switched access connection or virtual call. If the 
DTE is identified, then the PSPDN has a way to accrue charges to be paid on behalf 
of the DTE. That is, either the DTE or some other party is billable. 
Two components are required in order for a DTE to be considered identified: 

1. The DTE is administratively registered either: 

a. through direct arrangement with the PSPDN (ji.e., explicitly), or 


b. through pre-arrangement between the PSPDN and a PSN or another authority, and 
direct arrangement between the DTE and that authority Ci.e., not explicitly). 


2. The DTE identify is made known to the DCE during the switched access connection 
using one of the methods described in 2.4. 


| Only case l-a is applicable to XI. 


A DTE may incur charges even if not identified because some Administrations collect 
charges via the PSTN or CSPDN. 


[| This type of charging is not applicable to XI 
In any case, DTE identification is used for billing and accounting purposes. In 
addition to this basic function, DTE identification may optionally be used for one 
or both of the following purposes: 
a. enabling the PSPDN to provide a calling DTE address to a called DTE or 


b. enabling the DTE to obtain a different service than that offered to DTEs which 
do not establish an identity (see 2.3). 


2.e.2 DCE Identit 


When a network supports dial-out-by-the-PSPDN access to DTEs, there may be a 
requirement for identification of the network (i.e., DCE) to the DIE. In the case 
of dial-in-by-the-DTE access, although the identity of the DCE may already be known 
by the DTE (as the DTE originated the switched access connection), there may be a DTE 
requirement for identification of the network. 


| DCE identity is not required for SNAF and SNBU operation. 


2.3 SERVICE ASPECTS 


The switched access service given to a particular DTE is dependent upon: 

a. The PSPDN, 

b. The use/non-use of DTE identification, and 

c. The DTE service available to and chosen by the DTE. 
Three DTE service types are defined in this Recommendation (see 2.3.2 >. One of 
the DTE service types (Nonidentified) is independent of the specific DTE identity. 
One service type (Identified) may or may not be independent of the specific DTE 
identity. The third type (Customized) is related to the specific DTE identify in 
order to provide customization of some service aspects. 
The types of DTE service are further distinguished by whether there is a number 

oe by the network to be used to represent the DTE identify in the address fields 
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2. FUNCTIONAL ASPECTS 


2.1 DIAL-IN AND DIAL-OUT CONSIDERATIONS 


Dial-in operation allows a packet-mode DTE to access a PSPDN by means of selection 
procedures on a PSTN or CSPDN (see Figure 1). This operation is termed 
"dial-in-by-the-DTE" within this Recommendation. 


In the XI environment, "dial-in by the DTE" is referred to as Switched Network Access 
Facility (CSNAF) 


Figure 1. X.32 Dial-in-by-the-DTE operation 


For performing this operation, the DTE may use an automatic or manual calling 
procedure. 


Dial-out operation allows a PSPDN to access a packet-mode DTE by means of selection 
procedures on a PSTN or CSPDN (see Figure 2). This operation is termed 
"dial-out-by-the PSPDN" within this Recommendation. 


In the XI environment, "dial-out by the PSDN" is used for DTE access line back-up which 
is referred to as Switched Network Back-Up CSNBU). 


> PSTN ————————__——> DTE 


Figure 2. X.32 Dial-out-by-the-PSPDN operation 


For dial-out-by-the-PSPDN operation, the DTE should use the automatic answering but 
may use manual answering. 


Virtual call origination is independent of dial-in-by-the-DTE and 
dial-out-by-the-PSPDN operations. That 1s, a DTE that has been involved ina 
dial-in-by-the-DTE or dial-out-by-the-PSPDN operation may then initiate or receive 
virtual calls, subject to the limitations in specific situations as described in 3. 


2.2 IDENTIFICATION 


e.c-l DTE Identity 


When a DTE accesses a PSPDN through a PSN (Cdial-out-by-the-PSPDN), there may be a 
requirement for identification of the DTE to the DCE. 


Identification of the DTE to the DCE is required by XI for SNBU operation. It is not 
required for SNAF operation. 


The DTE "identity" is a means of referring to the DTE. The DTE identity is either 
explicitly agreed to between the DTE and the Administration or is implicitly 
acceptable to the Administration through agreements with other Administrations, 
organizations, or authorities. It may be composed of different elements such as a 


Functional aspects 157 


IBM Confidential 


1. SCOPE 


This Recommendation defines the functional and procedural aspects of the DTE/DCE 
anterface for packet-mode user classes of service DTEs as defined in Recommendations 

-l and X.10 for DTEs that access a PSPDN via public switched networks. In this 
Recommendation, a public switched network (PSN) is either a Public Switched Telephone 
Network (PSTN) or a Circuit Switched Public Data Network (CCSPDN). 


{ Note: Only PSTN is applicable to XI 

In the PSTN case, the X.32 DTE/DCE interface coincides with the interface between the 
DTE and the modem. This definition applies whether or not the Administration provides 
the DCE and regardless of how the interface is physically realized (Ce.g., whether or 
not the DTE and DCE are contained within the same enclosure). In either case, the 
PSN is involved only: 

a. in the establishment of the switched access path; 

b. to provide a transmission medium; and 


c. optionally, to provide a PSN number for purposes of identification and 
addressing. 


Administrations may offer one or more of the following physical level interfaces: 


1. For access by way of a CSPDN, either Recommendation X.21 or Recommendation X.21 
bis will be used, as described in 4.1 or 4.2, respectively. 


[ XI does not support X.21 switched interface 


2. For access by way of PSTN, appropriate V-series Recommendations will be used as 
described tn 4.3. 


The exact use of the relevant points in these Recommendations is given in 4. 

| Only duplex transmission facilities are supported by XI 

e. the link level, the LAPB link access procedure of Recommendation X.25 is used over 
a single switched physical circuit. The LAPB formats and procedures shall be in 
accordance with 2.2, 2.3, and 2.4% of Recommendation X.25, with additions as noted in 
5 of this Recommendation. 
The formats and the procedures at the packet level shall be in accordance with 


sections 3, 4, 5, 6, and 7 of Recommendation X.25 with the additions noted in 6 of 
this Recommendation. 
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REVISED RECOMMENDATION X.32 


INTERFACE BETWEEN DATA TERMINAL EQUIPMENT CDTE) 
AND DATA CIRCUIT-TERMINATING EQUIPMENT (DCE) FOR 
TERMINALS OPERATING IN THE PACKET-MODE AND ACCESSING 
A PACKET SWITCHED PUBLIC DATA NETWORK THROUGH 
A PUBLIC SWITCHED TELEPHONE NETWORK OR 
A CIRCUIT SWITCHED PUBLIC DATA NETWORK 


The establishing in various countries of Packet Switched Public Data Networks (PSPDN) 
providing data services creates the need to produce Recommendations to facilitate 
access to the PSPDN through a public switched telephone network (PSTN) or a circuit 
switched public data network CCSPDN). 


The CCITT, considering: 


a. 
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that Recommendation X.1 specifies the user classes of service for DTEs 
operating in the packet-mode, that Recommendation X.2 defines user facilities 
provided by public data networks, that Recommendations X.10 defines 
categories of access, that Recommendations X.21 and X.21 bis define DTE/DCE 
physical level interface characteristics, that Recommendation X.25 defines 
the interface between DTE and DCE for terminals operating in the packet-mode 
and connected to public data networks by dedicated lines, that Recommendations 
X.121 defines the international numbering plan for Public Data Networks (PDN), 
that Recommendation X.300 defines the principles and arrangements for 
interworking between PDNs and other public networks; 


that the V-series Recommendations define modem and interface characteristics 
for use of data services on the PSTN; 


that Recommendation T.70 defines the procedures and interfaces to be used by 
Telematic terminals, that Recommendation T.71 defines the extension of Link 
Access Procedure Balanced (CLAPB) procedure to be used in half-duplex 
transmission facilities (CLAPX); 


that a need has been identified to access a PSPDN through a PSTN or CSPDN, 
either because a dedicated circuit to the PSPDN is not justified or because 
global service availability is required with back-up network access via public 
switched networks; 


that some Administrations have considered the provision of Telematic services 
in different types of networks, e.g., PSPDN, PSTN and CSPDN; 


that, when this Recommendation is used to provide the Network service defined 
in Recommendation X.123, the physical, link and packet levels correspond to 
the Physical, Data link and Network layers respectively, as defined in 
Recommendation X.200; 


Cunanimously) declares the view 


that the functional and procedural aspects of packet-mode DTEs accessing a 
PSPDN through a PSTN or CSPDN are as specified in this Recommendation. 
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Correspondence with CCITT Recommendation X.32 


The DTE interface provided by XI is based on the 1987 provisional CCITT 
Recommendation X.32 (Grey Book, ISBN 92-61-02911-6). 


Notes: 


e In this part, portions of CCITT Recommendation X.32 are reproduced with special 
authorization of the International Telecommunications Union CITU). 


e The CCITT paragraph numbering has been used to facilitate comparison with the 
CCITT Recommendation, which is the authorative source. IBM has made every effort 
to accurately reproduce the CCITT Recommendation X.32. However errors may have 
been introduced inadvertently. To ensure complete accuracy, the customer should 
obtain the Recommendation directly from CCITT. 


e XI-specific text is indicated by a vertical line in the left margin. 


e Sections of the CCITT text not applicable to XI (such as additional facilities 
not implemented), are either omitted or marked "not applicable to XI". 


e Paragraphs and sentences related to features not supported by XI have been 
omitted. 
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3.1.3.2 Registered Address Provided 


In those cases when a registered address is provided, its use is described below. 


When an identified DTE makes a call request, the calling DTE address included in the 
ee" Call packet given to the called DTE is the registered address. 


pon receiving a call request with a called DTE address, that is the registered 
address, the PSPDN needs to determine whether or not to perform a 
dial-out-by-the-PSPDN operation. If there is a switched connection in existence on 
which the DTE identity that corresponds to the registered address has been 
established, that switched connection will be used by the PSPDN. Otherwise, the PSPDN 
will perform the dial-out-by-the-PSPDN operation. 


For SNBU , switched connection is established through network operator commands. If 


Soe connection has not been previously established, calls addressed to this DTE are 
cleared. 


The PSN number used for the dial-out-by-the-PSPDN is the registered address. 
3.1.4 Registered PSN Number 
When the "registered PSN number™ attribute is provided, its value is used by the PSPDN 


for dialing out to that DTE. 


3.1.5 x.25 Subscription Set 


The "X%.25 subscription set” attribute defines values for the X.25 link level options 

and system parameters and the X.25 packet level subscription-time optional user 

facilities which apply to switched access operation. Networks are not required to 

support all of the link level options and packet level subscription-time facilities, 

except as required in Recommendation X.2. The list of link level options and system 

parameters and packet level optional user facilities in the X.25 subscription set is 
q" in Table 4/7X.32 (see 3.3). 


ote: As defined in Recommendation X.25, the throughput class value is, at most, the 
speed of the access line (see the modem selection attribute, 3.1.8). However, in the 
case of a modem with automatic fall-back capability, the DCE shall set the default 
throughput class value to the maximum signalling rate of the modem used, unless the 
user has selected a lower value for the default throughput classes assignment 
facility. Whether some networks may take into account the signalling rate selected 
by the modems in fixing the default throughput class, if it is technically possible 
for the DCE to be aware of this rate, is left for further study. 


| XI does not automatically adapt the throughput class to the signalling rate when the 
| modem moves from normal to fall-back speed. 


3.1.5.1 Network Default 


| Not applicable in the XI environment. 


3.1.5.2 User Selectable 


When the X.25 subscription set is specified as user selectable, the value of each of 
the options, parameters, and facilities is available for customization by the user 
to a value from the set of values offered by the PSPDN. 


| In SNAF mode of operation, the X.25 subscription set is a function of the PSTN number 
| dialed by the DTE. 
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3.1.6 Logical Channels Assignment 


The "logical channels assignment" attribute defines the number of logical channels 
of each type assigned for a particular DTE. 


There is a default value assigned by the PSPDN for nonidentified DTEs (see below). 


3.1.6.1 Network Default 


Not applicable in the XI environment. 


3.1.6.2 User Selectable 

When the logical channels assignment 1s specified as user selectable, the number of 
logical channels of each type is set by the user, for the particular DTE identity, 
from the values supported by the network. This may tnclude the assignment of channels 
for permanent virtual circuits. 


In SNAF mode of operation, logical channels assignment is a function of the PSTN 
number dialed by the DTE. 


PVC service is available in SNAF and SNBU mode of operation. 


3.1.7 Dial-out-by-the-PSPDN Availability 


The "dial-out-by-the-PSPDN availability” attribute allows the use of 
dial-out-by-the-PSPDN operation. 
3.1.7.1 Network Default 


Not applicable in the XI environment. 


3.1.7.2 User Selectable 


When the dial-out-by-the-PSPDN availability is specified as user selectable, the 
capability to have dial-out-~by-the-PSPDN operation with a particular DTE is chosen 


by the user. When the dial-out-by-the-PSPDN availability is selected, the registered 
PSN number attribute must also be selected. 


With XI, this applies only to SNBU mode of operation 
For SNBU , switched connection is established through network operator commands. If 


this connection has not been previously established, calls adressed to this DTE are 
cleared. 


3.1.8 Modem Selection 


The "modem selection” attribute applies to dial-out-by-the-PSPDN operation and allows 
a DTE to choose modem characteristics or a user class of service, possibly other than 
the national default, from those offered by the network. Modem selection refers to 

the modem characteristics Cin the case of the PSTN) or the X.1 user class Cin the case 
of the CSPDN) that are used for switched access line operation at the physical level. 
See 4. Note that for dial-in-by-the-DTE through the PSTN, the modem characteristics 
of the PSPDN port dialed into are used. 


3.1.8.1 Network Default 


Not applicable in the XI environment. 


3.1.8.2 User Selectable 
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When the modem selection is specified as user selectable, the modem characteristics 


selected for this DTE identity, from those offered by the network, are used for 
dial-out-by-the-PSPDN through the PSTN. 


| With XI, modem and port selection are performed by the network operator. 


3.1.9 Temporary Location 


| Not applicable in the XI environment. 


3.1.10 Secure Dial-Back 


| Not applicable in the XI environment. 


3.1.11 DCE Identity Presentation 


| Not applicable in the XI environment. 


3.1.12 Link Level Address Assignment 


The "link level address assignment" attribute defines the mechanism used to determine 
the link level addresses. 


Note: Other methods of link level address assignment than those described below are 
for further study. 


eq. Network Default | 
XI assigns the link level address depending on the roles of equipment as DTE or DCE. 
| XI always acts as a DCE. 


3.1.12.2 User Selectable 


] Not applicable in the XI environment. 


3.2 DTE SERVICES SUMMARY 


The type of each attribute is given for the three DTE services in Table 3/X%.32. 
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TABLE 37X.32 


Summary of DTE services, 


SERVICES NONIDENTIFIED CUSTOMIZED 


CSNBU) 


CSNAF) 


Registered PSN 
number 


Logical channel 

assignment 

Dial-out-by-the- User sel. 
PSPDN availability 


Modem selection User sel. () 


Link level address ND ND 
assignment CDTE/DCE role)|CDTE/DCE role) 


not provided 

Network Default 

User selectable (subscription time) 
Provided 


ports, thus achieving ND-type DTE services. 


3.3 NONIDENTIFIED DTE SERVICE 


The values of the attributes for the nonidentified DIE service defined in 2.3.2.1 are 


shown in the "nonidentified™ column of Table 3/X.32. 


No DTE identity is established. 


No DTE identification method is used. 


The X.25 link level options and system parameters and the X.25 subscription-time 


optional user facilities are categorized for dial-in-by-the-DTE and 
dial-out-by-the-PSPDN operation in Table 4/X.32 as: 


= An "AVAIL-OPT™ optional user facility, 
offering the nonidentified DTE service and the availability of which is made 
known through either publication or use of the on-line facility registration 


facility; these facilities can be used without further request when operating 


on these networks. 


The use of this option, 


according to the PSTN number of the SNAF port dialed. 


The DTE may use any per-call X.25 facility that is supported by the PSPDN and that 


does not require prior subscription. 
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XI offers a set of DTE services equivalent to the 

Selection of one of the DTE services is done through dial-in 
to the appropriate port (Cor group of ports), specified by a PSTN number. The network 
to assign the same profile of DTE services to all dial-in 


which is available on some networks 


or the specific values attached to it, is selected 
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TABLE 4/7X.32 Cpart 1 of 2) 


Availability of link level options and system 
arameters and packet level subscription-time facilities in the 


nonidentified DTE service 
Capplies to SNAF mode of operation) 


Option, Parameter or Facility 
Capplication to all assigned Dial-in-by-the- 
logical channels) DTE operation 


LINK LEVEL 


Available with 
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TABLE 4/7X.32 Cpart 2 of 2) 


Option, Parameter or Facility 
Capplication to all assigned Dial-in-by-the- 
logical channels) DTE operation 


PACKET LEVEL Ccontinued) 


Default Throughput Classes AVAIL-OPT 
Assignment 
Flow Control Parameter 

AVAIL-OPT 


Negotiation 
AVAIL-OPT 


Available with 


- subscription-time 


Closed User Group Related Faci- 
lities 

- Closed User Group 
-~ Closed User Group with Outgoing 


Access AVAIL-OPT 
- Closed User Group with Incoming 
Access AVAIL-OPT 


- Incoming Calls Barred within a 
Closed User Group 

- Outgoing Calls Barred within a 

Closed User Group 


AVAIL-OPT 
AVAIL-OPT 


Option, Parameter or Facility 
Capplication to all assigned Dial-in-by-the- - 
logical channels) DTE operation 


Reverse Charging Acceptance AVAIL-OPT 
Call Redirection AVAIL-OPT 
Call Transfer AVAIL-OPT 


Available with 


EA CURR cagA SETS CONTRA GREED GRAD GUMNEES COED CORTES CENSTEDS SAEED ANTES GOT CATED SEATED AD AND LTS NPE TD SERED SSE NY CET OS AES ND SD SAD INLD SEND ARN AILS SAT CERISE ERD 


3.4% IDENTIFIED DTE SERVICE 


| Not applicable in the XI environment. 


3.5 CUSTOMIZED DTE SERVICE 
The values of the attributes for the customized DTE service (defined in 2.3.2.2) are 
shown tn the "customized™ column in Table 3/X.32. 


A DTE identity that has been explicitly agreed to with the PSPDN for obtaining the 
customized DTE service 1s provided to the PSPDN. 


The availability for customization of each X.25 link level option and system parameter 
and X.25 packet level subscription-time facility is given in Table 5/X.32. 
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TABLE 5/7X.32 Cpart 1 of 2) 
Availability for customization in the 
customized DTE service of the X.25 link level options 


and system parameters and the X.25 subscription-time facility 
Capplies to SNBU mode of operation) 


Option, Parameter or Facility Customization 
Available 
Link Level 


CUSTOM 
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TABLE 5/7X.32 Cpart 2 of 2) 


Option, Parameter or Facility 


Customization ®& 
Available 
Packet Level (continued) 


Nonstandard Default Packet Sizes CUSTOM 
Nonstandard Default Window Sizes | CUSTOM 
Default Throughput Classes Assignment CUSTOM 


Flow Control Parameter Negotiation 
- Subscription-time CUSTOM 


Closed User Group Related Facilities 
- Closed User Group CUSTOM 
Closed User Group with Outgoing Access CUSTOM 
Closed User Group with Incoming Access CUSTOM 
Incoming Calls Barred within a Closed User Group CUSTOM 
Outgoing Calls Barred within a Closed User Group CUSTOM 


Reverse Charging Acceptance CUSTOM 
Call Redirection CUSTOM 
Call transfer CUSTOM 


Scena can be chosen or set to a nondefault value by the DTE, if supported by the 


The DTE may use any per-call X.25 facility which is supported by the PSPDN and which 
does not require prior subscription. 


The DTE may use any per-call X.25 facility which is supported by the PSPDN and which Se 
requires a corresponding subscription-time facility to be selected, provided that the 
corresponding subscription-time facility has been selected. 
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§. INTERFACE CHARACTERISTICS (PHYSICAL LEVEL) 


Administration may offer one or more of the physical level interfaces specified below. 


46.1 X.21 INTERFACE 


Not applicable in the XI environment. 


4.2 X.2iBrs INTERFACE 


Not applicable in the XI environment. 


4.3 V-SERIES INTERFACE 


For establishment, maintenance, and disestablishment of a switched access path between 
a DTE and a PSPDN by way of a PSTN, the physical level interface shall be as described 
in the following points of this section. 


4.3.1 Modem Characteristics 


Administrations may choose to offer modem characteristics in accordance with any or 
all of the following: 


a. 1200 bit/s V.22, alternatives A, B or C, mode (i) 
b. 240071200 bit/s Y¥.22 bis, modes (1) or Ciii)d, or 
& V.26 ter, modes (1) or (111) 


c. 960074800 bit/s V.32 


This list of modems is applicable to SNAF mode of operation. They can be used also 
for back-up of DTE leased lines through the PSTN, if they are equipped with back-up 
features. For full support by XI of the SNBU mode of operation, IBM modems of the 586x 
family (5865/5866 models 2 and 3), equipped with a 4-wire PSTN coupler, are required. 
These IBM modems can also be used for SNAF operations. 


4.3.2 Procedures for Full Duplex Operational Phases 


When circuit 107 is in the ON condition, and when circuits 105, 106, 108, and 109, 
if provided , are in the ON condition, data exchanged on circuits 103 and 104 will 
be as described in subsequent sections of this Recommendation. 


Circuits 106 and 109 may enter the OFF condition due to momentary transmission 


failures or modem retraining. Higher layers should delay for several seconds before 
considering the interface to be non-operational. 


4.3.3 Procedures for Half Duplex Operational Phases 


Not applicable in the XI environment. 
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4.3.4 Origination Procedures 


For SNAF operations, DTEs may use either: 
a. The Automatic origination procedures described in 
3 of Recommendation V.25; 


b. The automatic origination procedures described in 4 or 5 of Recommendation 
V.25 bis 


c. The manual origination procedures of 6 of Recommendation V.25. 
d. The origination procedure of 586x modems. 


For SNBU operations, XI will use the automatic origination procedure of the 586x IBM 
modems, equipped with a ¢-wire coupler. 


Other origination procedures may be used, either manually or through external autocall 
equipment. XI does not provide specific support for these procedures. 


4.3.5 Answering Procedures 


For dial-out-by-the-PSPDN procedures, DTEs should use the automatic answering 
procedures of the 586x IBM modems. . 


If other V-series modems are used instead, DTEs should use the automatic answering 
procedures of Recommendations V.25 or V.25 bis. 


For dial-in-by-the-DTE, networks will use automatic answering procedures only. 


4.3.6 Disconnection Procedures 


DTEs and networks shall use the disconnection procedures specified in Recommendation 
V.24. 


4.3.7 Test Loops 

The definitions of test loops and the principles of maintenance testing using test 
loops are provided in Recommendation V.54. 

Descriptions of the test loops and the procedures for their use are given in the 
appropriate modem Recommendations. It should be noted that the procedures for loop 
testing vary among the several modem Recommendations. 


XI does not support V.54¢ loop setting. 


When using IBM 586x modems, the Line Problem Determination Aid (LPDA2) capabilities 
of these modems can be used for lines and modems diagnostic purposes 


Automatic activation by a DTE of test loops 2 and 4 in the DCE at the remote terminal 
1s not possible. 
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5. LINK ACCESS PROCEDURES ACROSS THE DTE/DCE INTERFACE 


5.1 INTRODUCTION 


This section specifies the mandatory and optional link level procedures that are 
employed to support switched access data interchange between a DCE and a DTE. 


5.1.1 Compatibility with the ISO Classes of Procedures 


The switched access link level procedures defined in this Recommendation use the 
principles and terminology of the High-level Data Link Control CHDLC) procedures 
specified by the International Organization for Standardization. 

DCE compatibility of operation with the ISO balanced classes of procedures (Class BA 
with options 2 and 8 Class BA with options 2, 8 and 10) is achieved using the LAPB 


procedure described in 2.2, 2.3, and 2.4% of Recommendation X.25. Class BA with 
options 2 and 8 CLAPB modulo 8) is available in all networks for switched access. 


5.1.2 Underlying Transmission Facility 


| The underlying transmission facility is duplex only. 


5.2 LINK LEVEL ADDRESS ASSIGNMENT 


Two alternative mechanisms for assigning the link level addresses are included in the 
procedures of this Recommendation. The conditions when each mechanism applies are 
specified in the link level address assignment attribute (see 3.1.12). 


@:1. address assignment depending upon the DTE/DCE role is offered by XI. 


5.2.1 Depending on Switched Access Call Direction 


| Not applicable in the XI environment. 


5.2.2 Depending on Roles of Equipment as DTE and DCE 


In accordance with the specifications in 2.4.2 of Recommendation X.25, the link level 
address assignment depends on the roles of the equipment as DTE and DCE such that the 
DCE transmits to the DTE the address A in command frames and the address B in response 
frames and the DTE does the opposite (i.e., transmits to the DCE address B in command 
frames and address A in response frames). 


5.3 USE OF XID FRAMES 


| Not applicable in the XI environment. 
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5.4% LINK SET-UP AND DISCONNECTION 


5.4.1 Link Set-Up 


The initiative of the link set-up is in the charge of the DTE in dial-in-by-the-DTE 
operation and of the DCE in dial-out-by-the-PSPDN operation. The DCE may also 
initiate link set-up in the case of dial-up-in-by-the-DTE operation; likewise, the 
DTE may also initiate Link set-up in the case of dial-out~be-the-PSPDN operation. 


With XI, the link set-up (that is, transmission of an SABM command), is always 
Initiated by the DTE. 


During the period between transmitting an SABM command and receiving the UA response, 
the DCE/DTE shall discard any frame except SABM, Disconnect (DISC), Unnumbered 


Acknowledge (UA) and Disconnected Mode (DM) as specified in 2.4.4.1 of Recommendation 
X.25. 


5.4.2 Disconnection 


Whenever the DCE needs to disconnect the switched access path and the link is not 
already in the disconnected phase, it should first disconnect the link. 


5.5 MULTILINK 


Not applicable in the XI environment. 


5.6 HALF-DUPLEX OPERATION 


Not applicable in the XI environment. 
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6. PACKET LEVEL 


6.1 SCOPE AND FIELD OF APPLICATION 


The formats and the procedures at the packet level shall be in accordance-with 3, 4, 
5, 6, and 7 of Recommendation X.25 with additions as noted in this section and in 7 
of this Recommendation. 


6.2 USE OF REGISTRATION PACKETS FOR IDENTIFICATION OF DTE AND/OR DCE AND FOR 
CONVEYANCE OF X.32 OPTIONAL USER FACILITIES 


|} Not applicable in the XI environment. 


6.3 IDENTIFICATION AND AUTHENTICATION OF THE DTE USING THE NUI FACILITY IN CALL 
SET-UP PACKETS 


| Not applicable in the XI environment. 
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7. X.32 PROCEDURES, FORMATS, AND FACILITIES 


7.1 IDENTIFICATION PROTOCOL 


Not applicable in the XI environment. 


7.2 PROCEDURES FOR X.32 OPTIONAL USER FACILITIES 


Not applicable in the XI environment. 


7.3. CODING OF THE IDENTIFICATION PROTOCOL ELEMENTS AND X.32 FACILITIES 


Not applicable in the XI environment. 


7.4 SECURITY GRADE 2 METHOD 


Not applicable in the XI environment. 


7.5 DCE TIMER T14 


The DCE may support a timer 114, the value of which should be made known to the 


At the expiration of timer T14, the DCE will disconnect the link, if connected, 
the switched access path. 


Timer 114 is started whenever a switched access path is established. Timer 1T14 
stopped when a virtual call(s) is established. The set-up of a PVC or DC on the 
switched access path causes T14 to be stopped. 

Timer T14 will be restarted when no assigned logical channels are active. 

The period of timer T14 shall be network dependent. 


For XI, T14 is optional, and can be set by the network service provider from 10 
180 seconds. 


7.6 DCE TIMER T15 


Not applicable in the XI environment. 
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APPENDIX A. ACTIONS TAKEN BY THE QUESTIONING AND CHALLENGED PARTIES 


| Not applicable in the XI environment. 
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APPENDIX B. ABBREVIATIONS 


AVAIL-BAS 
AVAIL-NS 
AVAIL-OPT 
AVAIL-RQ 


BA 


CSPDN 
CUSTOM 


DCE 
DIAG 
DISC 
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Available on all networks 

Available and selected by the network 
Available on some networks 

Available on some networks and must be requested 
Class of HDLC 

Circuit Switched Public Data Network 
Customized | 

Data Circuit-terminating Equipment 
Diagnostic element 

Disconnect 

Disconnected Mode 

Data Network Identification Code 
Data Switching Equipment 

Data Terminal Equipment 

Format Identifier 

High-level Data Link Control 
Half-duplex Transmission Module 
Identity element 

Integrated Services Digital Network 
International Organization for Standardization 
Number of outstanding I frames 

Link Access Procedure B 

Link Access Procedure - Half-duplex 
Parameter.... 

Parameter.... 

Network Default 

Nattonal Number 

Network Terminal Number 

Network User Identification 

Public Data Network 

Public Switched Network 

Packet Switched Public Data Network 
Public Switched Telephone Network 
Random Number element 


Reject 


XI DIE/DCE Interface Description 


RPOA 
RR 
RSA 
@acn 
SABME 
SIG 
SRES 
TCC 
exee 
UA 
UTC 
XCecs 
XID 
KT 
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Recognized Private Operating Agency 
Receive Ready 

Rivest, Shamir and Adleman algorithm 
Set Asynchronous Balanced Mode 

Set Asynchronous Balanced Mode Extended 
Signature element 

Signed Response element 

Telephone Country Code 

Timer... 

Unnumbered Acknowledge 

Coordinated Universal Time 


Counter... 


Exchange Identification CUnnumbered Format) 


Timer... 


Abbreviations 
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APPENDIX C. IMPLEMENTATION OF LAPX 


| Not applicable in the XI environment. 
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APPENDIX D. RSA PUBLIC KEY ALGORITHM 


[| Not applicable in the XI environment. 
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APPENDIX E. RELATIONSHIP OF T14 TO THE DIFFERENT METHODS OF DTE IDENTIFICATION 


| Not applicable in the XI environment. 
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APPENDIX F. LIST OF TERMS 


The following terms are contained in this Recommendation. References to definitions, 
mplicit or explicit, are included where appropriate and where available. 


Authentication: cont. in X.32, impl. def. in X.32 


Challenged party: cont. in X.32, impl. def. in X.32 
Closed User Group: cont. in X.32, impl. def. in X.25 
Counter: cont. in X.32, impl. def. in X.32 

Customized DTE service: cont. in X.32, impl. def. in X.32 


Data Network Identification Code: cont. in X.32, impl. def. in X.121 
Dial-in-by-the-DTE: cont. in X.32, impl. def. in X.32 
Dial-out-by-the-PSPDN: cont. in X.32, impl. def. in X.32 

DCE identity: cont. in X.32, impl. def. in X.32 

DTE tdentity: cont. in X.32, impl. def. in X.32 

DTE profile: cont. in X.32, impl. def. in X.32 

DTE service type: cont. in X.32, impl. def. in X.32 


Exchange identification: cont. in X.32, impl. def. in X.32 
Failure detection: cont. in X.32, impl. def. in X.21, impl. def in X. 21 bis 


Half-duplex transmission module: cont. in X.32, impl. def. in X.32 
High-level Data Link Control: cont. in X.32, impl. def. in X.25 


Identified DIE service: cont. in X.32, impl. def. tn X.32 
Identification: cont. tn X.32, impl. def. in X.32 

Interface characteristics: cont. in X.32, impl. def. in X.32 
International Numbering Plan: cont. in X.32, impl. def. in X.121 
Link access procedure: cont. in X.32, impl. def. in X.32 

Link level address assignment: cont. tn X.32, impl. def. tn X.32 
Local Charging Prevention: cont. in X.32, impl. def. in X.25 
Logical channel assignment: cont. tin X.32, impl. def. in X.25 


Modem characteristics: cont. in X.32, impl. def. tn V-Rec. 
odem selection: cont. in X.32, impl. def. in X.32 
ultilink: cont. in X.32, impl. def. in X.75 


Nonidentified DTE service: cont. in X.32, impl. def. in X.32 
NUI override permission: cont. in X.32>, impl. def. in X.de 


On-line facility registration: cont. in X.32, impl. def. in X.32 
Optional user facility: cont. tn X.32, expl. def. tn X.15 


Permanent virtual circuit: cont. tin X.32, impl. def. in X.25 
Questioning party: cont. in X.32, impl. def. in X.32 
Registered PSN number: cont. in X.32, impl. def. in X.32 
Registration procedure: cont. in X.32, impl. def. tin X.25 
RSA public key algorithm: cont. in X.32, impl. def. in X.32 


Secure dial-back: cont. in X.32, impl. def. in X.32 
Security grade: cont. in X.32, impl. def. in X.32 


Temporary location: cont. in X.32, impl. def. in X.32 

Test loops: cont. in X.32, impl. def. in X.150, impl. def. in V.54 
Timer: cont. in X.32, impl. def. in X.32 

User class of service: cont. in X.32, expl. def. in X.15 


Virtual call: cont. in X.32, impl. def. in X.25. 
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ABBREVIATIONS 


CCITT 


CUDF 
CUG 
DCE 


DISC 
DM 
DSP 
DTE 
FCS 
FRR 
GFID 
GW-DTE 
HDLC 
IDI 
Iso 


LAP 
LAPB 


LC 
MLP 
NCP 
NSAP 
NSF 


International Telegraph and 
Telephone Consultative 
Committee 

Call or Clear User Data Field 
Closed User Group 


Data Circuit-Terminating 
Equipment 


- Disconnect 


Disconnected Mode 

Domain Specific Portion 

Data Terminal Equipment 
Frame Check Sequence 

Frame Reject 

General Format Identifier 
ateway-DTE 

High Level Data Link Control 
Initial Domain Identifier 


International Organization for 
Standardization 


Link Access Procedure 


Link Access Procedure 
Balanced, 


Logical Channel 

Multilink Procedure 

Network Control Program 
Network Service Access Point 


X.25 SNA Network Supervisory 
Function 
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PAD 
PPSDN 


PRPQ 


PSDN 
PS 
PVC 
Qos 
REJ 
RNR 
RPOA 


RR 
SABM 
SLP 
SNA 
SVC 
SYSGEN 
TC 

UA 

vc 


WS 
XI 
372Xx 


Packet Assembly/Disassembly 


Public Packet-Switched Data 
Network 


Programming Request for Price 
Quotation 


Packet-Switched Data Network 
Packet Size 

Permanent Virtual Circuit 
Quality of Service 

Reject 

Receive Not Ready 


Recognized Private 
Organization Agency 


Receive Ready 

Set Asynchronous Balanced Mode 
Single Link Procedure 

System Network Architecture 
Switched Virtual Circuit 

ystem Generation 

Throughput Class 

Unnumbered Acknowledgment 


C1) Virtual Circuit, (2) 
Virtual Call 


Window Size 
X.25 SNA Interconnection 


IBM 3725/3720 Communication 
Controller 
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GLOSSARY 


Definition of terms 


his glossary contains definitions 
reprinted from: 


(1) The American National Dictionary for 
Information Processing, copyright 1977 
by the Computer and Business Equipment 
Manufacturers Association, copies of 
which may be purchased from the American 
National Standards Institute at 1430 
Broadway, New York, New York 10018. 
These definitions are identified by an 
asterisk (%). 


(2) The ISO Vocabulary of Data 
Processing, developed by the 
International Standards Organization, 
Technical Committee 97, Subcommittee 1. 
Definitions from published sections of 
this vocabulary are identified by the 
symbol (1I1S0) preceding the definition. 
Definitions from draft proposals and 
working papers under development by the 
ISO/TC97 vocabulary subcommittee are 
identified by the symbol (1TC97), 
indicating that final agreement has not 
yet been reached among its participating 
members. 


(3) The CCITT Sixth Plenary Assembly 


Orange Book, Terms and Definitions, 
published by the International 
Telecommunication Union, Geneva, 1978, 
and subsequent extensions. These are 
1dentified by the symbol (CCITT/ITU) 
@ rn ecedi ng the definition. 


barring: See calls barred. 

byte: A sequence of eight adjacent 
binary digits that are operated upon as 
a unit and that constitute the smallest 
addressable unit in the system. 


call: cCCCITT/ITU) A transmission for the 
purpose of identifying the transmitting 
station for which the transmission 15 
intended. 


call accepted packet: A call supervision 
packet that a called DTE transmits to 
indicate to the DCE that it accepts the 
incoming call. 


Call collision: A condition that occurs 
when a DTE and a DCE simultaneously 
transmit a call request packet and an 
incoming call packet over the same 
logical channel. See also clear 
collision, reset collision. 


call connected packet: A call 
supervision packet that a DCE transmits 
to indicate to a calling DTE that the 


connection for the call has been 
completely established. 


call redirection: C(CCITT/ITU) An 
optional user facility agreed for a 
period of time. This user facility, if 
subscribed to, redirects tncoming calls 
destined to a DTE when (1) the DTE is out 
of order, or (2) the DTE is busy. 


call redirection notification: 
(CCITT/ITU) A user facility used by the 
DCE in the tncoming call packet to inform 
the alternate DTE that the call has been 
redirected, why the call was redirected, 
and the address of the originally called 
DTE. 


call request packet: A call supervision 
packet that a DTE transmits to ask that 
a connection for a call be established 
throughout the network. 


call supervision packet: A packet used 
to establish or clear a call at the 
interface between the DTE and the DCE. 


call transfer: An XI-specific facility 
that permits a DTE (CDTE A) communicating 
through an SVC with another DTE CDTE B) 
to locally clear the call with DTE B and 
to redirect that call to a third DTE CDTE 
C) in such a way that the only effect on 
DTE B is the necessity for a reset 
procedure to resynchronize packet level 
states. 


called line address modified 
notification: CCCITT/ITU) An optional 
user facility used by the DCE tn the call 
connected or clear indication packets to 
inform the calling DTE as to why the 
called address in the packet is different 
from that specified in the call request 
packet. 


calling: (1C97) The process of 
transmitting selection signals in order 
to establish a connection between data 
stations. 


calls barred: (CCITT/ITU) A facility 
that permits a DTE to make outgoing or 
to receive incoming calls only Cbut not 
both). 


cause code: The code used in the cause 
field of clear, reset, and restart 
request packets to tndicate the reason 
for the request. 


Clear collision: A condition that occurs 
when a DTE and a DCE simultaneously 
transmit a clear request packet anda 
clear indication packet over tha same 
logical channel. See also call collision, 
reset collision. 


clear confirmation packet: 
confirmation packet. 


See DCE clear 
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Clear indication packet: A call 
supervision packet that a DCE transmits 
to inform a DTE that a call has been 
cleared. 


clear request packet: A call supervision 
packet that a DTE transmits to ask that 
a call be cleared. 


Closed user group (CUG): (TC97) Ina 
group of users, a subgroup that is 
assigned a facility that enables a member 
of one subgroup to communicate only with 
other members of the subgroup. 


Note: A DTE may belong to more than one 
closed user group. 


communication controller: A type of 
communication control unit whose 
operations are controlled by one or more 
programs stored and executed in the unit, 
for example the IBM 3725 Communication 
Controller. 


communication controller node: A | 
communication controller that contains a 
network control program. 


D bit: Delivery confirmation bit, used 
in a packet header to request 
acknowledgement from its destination 
upon receipt. 


data circuit-terminating equipment 
(DCE): (€1TC97) The equipment installed 
at the user's premises that provides all 
the functions required to establish, 
maintain, and terminate a connection, and 
the signal conversion and coding between 
the data terminal equipment (DTE) and the 
line. 


Note: The DCE may be separate equipment 
or an tntegral part of other equipment. 


data packet: (CCITT/ITU) A packet used 
for the transmission of user data ona 
virtual circuit at the DTE/DCE interface. 


data terminal equipment (DTE): (¢1C97) 
That part of a data station that serves 
as a data source, data sink, or both, and 
provides for the data communication 
control function according to protocols. 


DCE clear confirmation packet: 
supervision packet that a DCE 
transmits to confirm that a call has 
been cleared. 


A call 


dedicated logical channel: The 
restriction of a logical channel for use 
on virtual circuits established tn a 
particular way (by an incoming call, 
outgoing call, or call in either 
direction, or to a permanent virtual 
circuit). 


default external addressing: Routing 
through a default gateway DTE when a 
called DTE address commences with neither 
a RAP nor a XAP. 
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default packet size: The packet size 
used in the absence of flow control 
parameter negotiation. 


default packet window size: The packet 
window size used in the absence of flow 
control parameter negotiation. 


default throughput class: The 
throughput class used in the absence of 
throughput class negotiation. 


default transit delay: The transit delay 
used in the absence of transit delay 
selection and indication facility. 


diagnostic code: A code used in 
diagnosic packets and in clear, reset, 
and restart indication packets to 
indicate errors, failures, or inherent 
Incompatibilities of a DTE with the 
network or with another DTE. 


diagnostic packet: <A packet used to 
provide diagnostic direct call 
information from a DCE to a DTE. 


direct call: An XI specific facility 
which consists in assigning to one or 
more than one logical channel of a 
DTE/DCE interface a complementary 
subscription parameter allowing the DTE 
to initiate an SVC set-up procedure on 
selected logical channels with 
parameters defined at subscription time 
(mainly the address of the called DTE). 


discarded packet: A packet that is 
intentionally destroyed. 


DTE address: (1) Home DTE address. (2) 
DTE number within an XI node. 


DTE clear confirmation packet: A call 
supervision packet that a DTE transmits 
to confirm that a call has been cleared. 


DTE generic address: 
address. 


See generic 


DTE/DCE interface: C(CCITT/YITU) The 
physical interface elements and the link 
access procedures between data terminal 
equipment CDTE) and data 
circulit-terminating equipment CDCE). 


extended packet sequence numbering: 
Packet sequence numbering with modulo 
128. 


external address: This is used for DTEs 
attached to an XI node via an external 
X.25 network and consists of a prefix 
identifying the external network 
followed by an address of up to 14 
digits. Contrast with relative address. 


flag (F) sequence: The unique sequence 
of eight bits €01111110) employed to 
delimit the opening and closing of a 
frame. 


flow control: (NPP/GI) In SNA, the 
process of managing the rate at which 


IBM Confidential 


data traffic passes between components 
of the network. The purpose of flow 
control is to optimize the rate of flow 
of message units with minimum congestion 
in the network; that is, to neither 

verflow the buffers at the receiver or 
6: intermediate routing nodes, nor leave 
the receiver waiting for more message 
units. | 


flow control parameter negotiation: A 
packet-switched data network optional 
facility that allows a DTE to negotiate 
the packet size and window size for 
communication with another DTE. 


frame: The link-level unit for 
transmitting commands, responses, or 
packets over the physical circuit between 
a DTE and an adjacent DCE. It is a 
sequence of contiguous bits bracketed by 
and including opening and closing flag 
sequences. 


frame check sequence (FCS): The field 
immediately preceding the closing flag 
sequence of a frame, containing the bit 
sequence that provides for the detection 
of transmission errors by the receiver. 


frame Window size: The number of I 
frames a DTE or DCE can send across a 
link before waiting for authorization to 
send another I frame. The window is the 
main mechanism of pacing or flow control 
of frames. 


gateway DTE (GN-DTE): The XI function 
that provides an interface between an XI 
eo and an external X.25 network. 


general format identifier (GFID): Bits 
0 through 3 of the first byte of an X.25 
packet, containing the Q-bit, the D-bit, 
and the modulo. 


generic address: The lowest home DTE 
address for a DTE when sub-addressing 1s 
used. 


group: See closed user group, logical 
channel group, GROUP. 


home DTE address: A component of the 
relative address for a DTE attached 
locally to an XI node. It consists of the 
XI node number and the DTE number. 

I frame: See information frame. 


incoming: From DCE to DTE or from remote 
DXE to local DXE. Contrast with outgoing. 


incoming call packet: A call supervision 
packet that a DCE transmits to inform a 
Sart DTE that another DTE has requested 
a call. 


information (I) frame: A frame in I 
format, used for numbered information 
transfer. See also supervisory frame, 
unnumbered frame. 


interrupt packet: A packet used to 
interrupt a virtual circuit at the 
interface between the DCE and the DTE. 


leased line: 
line. 


Synonym for nonswitched 


line: Any physical medium, such as a 
wire or microwave beam, that 1s used to 
transmit data. 


link: (1) * The physical means of 
connecting one location to another for 
the purpose of transmitting and receiving 
data. 


(2) In SNA, the interconnecting data 
circuit between two or more equipments 
operating in accordance with a Link 
protocol; it does not include the data 
source and the data sink. 


link access procedure: The link level 
elements used for data tnterchange 
between a DCE and a DTE operating in user 
classes of service 8 to 11, as specified 
in CCITT Recommendation X.1. a linkage 
editor. 


link level: The level of a communication 
protocol that specifies how data 
transferred across a link is formatted, 
checked, and recovered. Contrast with 
packet level, physical level. 


local: Attached to this node or within 
this node. 


logical channel (LC): CCCITT/ITU) In 
packet mode operation, a means of two-way 
simultaneous transmission across a data 
link, comprising associated send and 
receive channels. 


Notes €1) A number of logical channels 
may be derived from a data link by packet 
interleaving. 


(2) Several logical channels may exist 
on the same data link. 


logical channel group: A group of 
logical channels on a single link. 


logical channel group number (LCGN): A 
number identifying a group of logical 
channels within a link. 


logical channel identifier: The 
combination of a logical channel group 
number and a logical channel number (Cin 
that sequence). 


logical channel number (LCN): (1) A 
number identifying an individual logical 
channel within a logical channel group. 
(2) In NSF operator commands, a number 
identifying a logical channel within a 
link, and equal to LCGNX256 + LCN. 


M bit: More data bit, used in a packet 
header to indicate that more data follows 
that is logically connected with this 
packet. 
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modulo: The numerical base used for 
packet sequence numbering. 


multichannel Link (MCH): CCCITT/ITU) A 
means of enabling a data terminal 
equipment (DTE) to have several access 
channels to the data network over a 
single circuit. Three likely methods 
have been identified: packet 
interleaving, byte interleaving, and bit 
interleaving. 


NCP node: In an SNA network, a 
communication controller with NCP 
installed. 


Network Control Program (NCP): 
licensed program that provides 
communication controller support for the 
physical management of a network; it 
controls attached links and devices, 
routes data, and performs error recovery 
routines, 


An IBM 


nonswitched line: A telecommunication 

line on which connections do not have to 

be established by dialing. Synonymous 

aie leased line. Contrast with switched 
ine. 


non-XI node: In an XI network, a 
communication controller that does not 
have XI installed. It can act only as a 
transit node. 


normal DTE: <Any DTE other than a gateway 
DTE or NPSI DTE. 


NPSI: See X.25 NCP Packet Switching 
Interface. 


NPSI bridge: The XI function that 
interfaces between XI and NPSI in the 
same XI node. 


NPSI DTE: A DTE within NPSI, defined by 
an tndividual pseudo-link with XI in the 
same XI node. 


NPSI node: In an SNA network, a 
communication controller with NPSI 
installed. 


octet: (ISO) A byte composed of eight 
binary elements. 


one-way logical channel incoming: An 
optional user facility that restricts the 
logical channel use to virtual circuits 
established by incoming calls. 


one-Way logical channel outgoing: An 
optional user facility that restricts the 
logical channel use to virtual circuits 
established by outgoing calls. 


optional user facilities: Facilities 
that a user of a packet-switched data 
network can request when establishing a 
virtual circuit. These include closed 
user group, reverse charging, and 
throughput class negotiation. 
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outgoing: From DTE to DCE or from local 
DXE to remote DXE. Contrast with 
incoming. 


packet: (1C97) A sequence of binary 
digits including data and call control 
signals that is switched as a composite 
whole. The data, call control signals 
and possibly error control information, 
are in a specific format. 


packet assembly/disassembly (PAD): 
C(CCITT/ITU) A user facility that permits 
non-packet mode terminals to exchange 
data in the packet mode. 


packet level: The packet format and 

control procedures for the exchange of 
packets containing control information 
and user data between the DTE and the 


DCE. Contrast with link level, physical 


level. 


packet level protocol (PLP): A protocol 
that defines communication at the packet 
level. 


packet sequencing: (1TC97) A process of 
ensuring that packets are delivered to 
the receiving DTE in the same sequence 
as they were transmitted by the sending 
DTE. 7 


packet size: 
packet. 


The length Cin bytes) of a 


packet-switched data network (PSDNJ: A 
network that uses packet switching as a 
means of transmitting data. 


packet switching: (1TC97) The process of 
routing and transferring data by means 
of addressed packets so that a channel 
iS occupied only during the transmission 
of a packet; upon completion of the 
transmission, the channel 1s made 
available for the transfer of other 
packets. Synonymous with packet mode 
operation. Contrast with circuit 
switching. 


packet type: The type of packet sent 
between a DTE and DCE; for example, a 
call request, clear indication, DTE data, 
or diagnostic packet. 


packet Window size: The number of data 
packets a DTE or DCE can send across a 
logical channel before waiting for 
authorization to send another data 
packet. The window 1s the matn mechanism 
of pacing or flow control of packets. 


permanent virtual circuit (Pvc): A 
virtual circuit that has a logical 
channel permanently assigned to it at 
each DTE. The usual call establishment 
protocol is therefore not required. 


physical circuit: CCCITT/ITU) A circuit 
created with hardware rather than by 
multiplexing. Contrast with virtual 
circuit. 
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physical level: The mechanical, 
electrical, functional and procedural 
media used to activate, maintain and 
deactivate the physical link between the 
DTE and the DCE. Contrast with link 
level, packet level. 


Piggybacking: The carrying of flow 
control information in a data packet. 


primary end: The end of a PVC that 
controls activation/deactivation of the 
PVC and at which statistics and 
accounting information are collected. 
Contrast with secondary end. 


public packet-switched data network 
(PPSDN)J: A packet-switched data network 
operated for public subscribers. 


public switched telephone network 
(PSTN): <A circuit-switched voice 
network operated for public subscribers. 


Q bit: Qualified data bit, used in a 
packet header to distinguish the 
qualified data from other data. 


Recommendation X.25 (Geneva 1976, 1980; 
Torremolinos 1984): <A CCITT 
recommendation for the interface between 
data terminal equipment and 
packet-switched data networks. See also 
packet switching. 


relative address: This is used for DTEs 
attached directly to an XI node and 
consists of a prefix followed by an XI 
node number and a DTE number. See 
elative address prefix, home DTE 
ddress. Contrast with external address. 


relative address prefix: The initial 
digit in the relative address of a DTE 
that identifies the network (XI, PSDN) 
to which the DTE is attached. 


remote: Attached to another node or 
within the other node. 


reset collision: A condition that occurs 
when a DTE and a DCE simultaneously 
transmit a reset request packet anda 
reset indication packet over the same 
logical channel. See also call collision, 
clear collision. 


reset packet: A packet used to reset a 
virtual circuit at the interface between 
the DCE and the DTE. 


restart packet: <A packet used to restart 
a virtual circuit at the interface 
between the DCE and the DTE. 


reverse charging: An optional facility 
of a packet-switched data network that 
enables a DTE to request that the cost 
of a session it initiates be charged to 
the DTE that is called. See also 
optional user facilities. 


reverse charging acceptance: A facility 
that enables a DTE to receive incoming 
packets that request reverse charging. 


RNR packet: A packet used by a DTE or 
by a DCE to indicate a temporary 
inability to accept additional packets 
for a given virtual call or permanent 
virtual circuit. 


RR packet: A packet used by a DTE or by 
a DCE to indicate that it is ready to 
receive data packets within the window. 
S frame: See supervisory frame 
secondary end: The opposite end of a PVC 


from the primary end. Contrast with 
primary end. 


segment: The measurement unit used for 
charging for the volume of information 
transmitted in a packet-switched 
service; its length is 64 octets. 


sequence number: A number assigned to a 
particular frame or packet to control the 
transmission flow and receipt of data. 


Sub-address: A field within a DTE 
address that distinguishes different 
addresses within the DTE, used for 
example when the DTE is a concentrator 
or multiplexer. 


supervisory (S) frame: A frame in 
supervisory format, used to transfer 
supervisory control functions. Contrast 
with information frame, unnumbered 
frame. 


switched line: <A telecommunication line 
in which the connection is established 
by dialing. Contrast with nonswitched 
line. 


switched network access facility 

(SNAFJ: In XI, an optional facility that 
allows a user to attach an X.25 DTE to 
an XI node via a switched line of a 
public switched telephone network. 


switched network backup (SNBUJ: In XI 
an optional facility that allows a user 
to specify for DTE links a switched line 
to be used as an alternative path if the 
primary line becomes unavailable or 
unusable. 


switched virtual circuit (SVC): A 
virtual circuit that is established by 
one DTE making a call request to the 
network. It is released when a clear 
request is accepted. 


system generation (SYSGEN): * (150) The 
process of selecting optional parts of 
an operating system and of creating a 
particular operating system tailored to 
the requirements of a data processing 
installation. 


Systems Network Architecture (SNA): The 
description of the logical structure, 
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formats, protocols, and operational 
sequences for transmitting information 
units through and controlling the 
configuration and operation of networks. 


Note: The layered structure of SNA allows 
the ultimate origins and destinations of 
Information (that is, the end users) to 
be independent of, and unaffected by, the 
specific SNA network services and 
facilities used for information 
-exchange. 


throughput class: A class of service 
that determines the speed at which 
packets travel through a packet-switched 
data network. 


throughput class negotiation: A 
packet-switched data network optional 
facility that allows a DTE to negotiate 
the speed at which its packets travel 
through the packet-switched data 
network. 


time-out: (CCITT/ITU) A parameter 
related to an enforced event designed to 
occur at the conclusion of a 
predetermined elapsed time. 


transit delay: The time taken by packets 
to transit a specified part of a network, 
such as between two nodes. 


transit node: In an XI network, a 
communication controller through which 
packets pass without any processing by 
XI. Both XI nodes and non-XI nodes can 
be transit nodes. 


two-way logical channel: A logical 
channel that can be used in virtual 
circuits that are established by either 
an incoming call or an outgoing call. 

U frame: See unnumbered frame 
unnumbered (U) frame: A frame in 
unnumbered format, used to transfer 
unnumbered control functions. Contrast 
with information frame, supervisory 
frame. 


virtual call: CCCITT/ITU) A user 
facility in which a call set-up procedure 
and a call clearing procedure will 
determine a period of communication 
between two DTEs in which user's data 
will be transferred in the network in the 
packet mode of operation. All the user's 
data is delivered from the network in the 
same order in which it is received by the 
network. Synonymous with switched 
virtual circuit. 


virtual circuit (VC): A logical 


connection established between two DTEs. 
It can be permanent, that is, defined 
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when you subscribe to your network port, 
or it can be dynamically established when 
creating a switched virtual circuit. 
Contrast with physical circuit. 


Virtual Telecommunications Access Method 
(VTAM): CNPP/GI) An IBM licensed program 
that controls communication and the flow 
of data in an SNA network. It provides 
single domain, multiple domain, and 
interconnected network capability. 


VTAM: C(NPP/GI) Virtual 
Telecommunications Access Method CIBM 
licensed program). Its full name is 
Advanced Communications Function for the 


Virtual Telecommunications Access 
Method. 


WINdOW Size: See frame window size, 
packet window size. 


Wraparound: The continuation of an 
operation from the maximum addressable 
location in storage to the first 
addressable location. 


XI gateway: An XI node that is used to 
interface to an external X.25 network. 


XI identifier: 
local address. 


An XI network address or. 


XI networks: 
by SNA links. 


A set of XI nodes connected 


XI node: A communication controller with 
XI installed. 
X.25: See Recommendation X.25. 


X.25 NCP Packet SWitching Interface 
(NPSI}: An IBM licensed program that 
allows SNA users to communicate over 
packet-switched data networks that have | 
interfaces complying with Recommendation 
X.25 (Geneva 1980) of the International 
Telegraph and Telephone Consultative 
Committee (CCITT). It allows SNA 
programs to communicate with SNA 
equipment or with non-SNA equipment over 
such networks. 


X.25 network: A packet-switched data 
network that provides a DTE/DCE interface 
conforming to the X.25 recommendation. 


X.25 SNA Interconnection (XI): 
Licensed Program that runs ina 
communication controller to provide 
packet-level handling for X.25 traffic. 


An IBM 


X.25 SNA Network Supervisory Function 
(NSFJ: An IBM Licensed Program that runs 
in an SNA host processor to provide 
operator and report-gathering functions 
for an XI network. 
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